The Basic Way of handling data is with the Data and Read statements, which fell by the wayside when QuickBASIC became Visual Basic. The Data statement allowed you to define tables of data of mixed types. At design time, you could initialize integers, real numbers, and strings all together in one big table; then, at run time, you could read those statements into variables. It wasn’t a great syntax, but it did allow you to initialize simple data types at design time, something that Visual Basic still won’t do. In Windows programming, however, what you really need is a way to initialize and read larger, less formatted kinds of data—bitmaps, icons, metafiles, forms, and objects.
The Visual Basic Way of handling data is to allow initialization of properties (including pictures that contain bitmaps, icons, and metafiles) in the Properties window. In early versions of Visual Basic, the actual data was stored directly in the source file and eventually compiled into the executable file. This was easy to do because, historically, Visual Basic source files were encoded and packed. Because the format wasn’t documented, Visual Basic could cram data and code together however it liked, as long as it knew how to decode the resulting files.
But binary source files in an undocumented format caused a lot of problems, especially for source-code control programs. Visual Basic version 2 added a text format for source files. All the simple property data was arranged in the hierarchical table format you’re familiar with if you’ve ever looked at a Visual Basic source file with a text editor. The binary data was crammed into FRX files in some undocumented format. This worked so well that starting with version 4, all source files were saved in text format. One curious limitation remains: you can initialize the properties of forms and controls at design time, but you can’t initialize variables or objects declared in code.
The Windows Way of storing binary data is very different from the Visual Basic Way. In other programming languages, you maintain binary data for your programs by storing it in resources. Using a visual tool called a resource editor, you can create resources such as bitmaps, icons, cursors, menus, and dialog boxes just the way you want them to look in your program. This editor stores the resources in a text file (an RC file) that looks a bit like a simplified Pascal source file. You then use a resource compiler to compile RC files into binary RES files, which are in turn inserted directly into executable files so that the resources and the code share the same EXE file. You write code in whatever language you choose to load the resource data at run time.
This seems like a fairly complicated way to do by hand what Visual Basic does automatically. But the Windows Way offers one big advantage over the Visual Basic Way: in Visual Basic, the binary data is tied to the source file. Each FRM file has a matching FRX; if you change the FRM file, you automatically change the FRX. In other words, if you want English, German, and Dutch versions of your program, you must create three versions of each form. In Windows, the resource file is independent of source files. You can create English, German, and Dutch versions of your resource file and combine any one with the executable file without changing a line of source code.
Because many Americans (I’m not without sin) tend to assume that English is the only language worth worrying about, you might not have heard much about this limitation in magazine articles or online forums. But you can bet that Microsoft has heard a lot of complaints about it from foreign programmers as well as from English-language developers who want to sell their software in non-English-speaking countries. As a result, Visual Basic allows you to use resources in Basic programs. The Windows Way, in the form of RES files, and the Visual Basic Way, in the form of FRX files, can exist side by side in the same program.