For long-time professional programmers, this system of operation is somewhat peculiar, even foreign. For a programmer not to have her source code manage 100 percent of whatever is seen, done, and transacted within her program can give her an awkward feeling--a bit like driving a car that is accustomed to accelerating itself. This is especially true for a programmer whose every program could be transcribed in its entirety onto line printer paper. Yet if statistics are any indicator, this awkwardness doesn't linger for long, and soon a sense of indulgence takesover.

Actually programming, byte by byte, the graphical resources used by a Windows application in the construction of the parts of a dialog panel or a window is extremely difficult work. You won't have to do any of this work with VBA because the way Windows is built, these same resources are supplied by little component programs that take care of the difficult assembly of controls on a dialog panel or window on your behalf. Each text field, drop-down list box, and scrollbar is its own little program, continually communicating its status to Windows. That data is then made available to the VBA interpreter by Windows so that VBA can manage the behaviour of those controls.

So with VBA, you assemble a dialog panel not with VBA instructions, but with your mouse and an ounce or two of manual dexterity. Using the mouse, you assemble the controls onscreen where you want them to be, and then set them up to behave the way you want them to behave when the VBA module first starts up. Because controls are representedin VBA by objects, you set their initial appearance and behaviour by means of these objects' properties. This isn't a difficult matter; you simply enter this data into the Properties window of the VBA workspace.

While this does involve typing, it's more on the order of filling in a form than writing a procedure. To set the initial appearance and default behaviour of control, in most case, you need not write any VBA instructions.

There are exceptions (with anything built by Microsoft, there always are exceptions), but you won't encounter them until you begin building complex control mechanisms. Setting up simple dialog boxes requires zero instructions.

What are controls?
For most Windows programs, the most common gadgets you find on dialog panels and toolbars, such as check boxes and fields where you type in text, are actually provided by small, independent programs. The gadgets themselves are called controls, while the programs that manage them are called components.

For example, when you look at adialog panel or a form that contains several fields where you type in text, you're most likely looking at several distinct instances of one running component, namely the text box or text field component.

A library is a file containing many small programs
You do not write the code for the component within VBA; this is a job that is already done for you. (If you want to write your own components, you could use Visual Basic 5.0 Control Creation Edition.) In Windows, a library is a single file that contains the machine code (the compiled program) for one or more components. This is pre-existent code that VBA already knows how to contact and manage.

To write a VBA module using drop-in controls, you do not need to know the identity or whereabouts of this library file. However, if you intend to distribute your VBA module to others, you may need to make certain that your recipients have the same library file that you used for your controls. If your module uses only Forms 2.0 controls, you're safe, because ifyour recipients have Office 97 (and they have to in order to run your VBA module anyway), they have the Forms 2.0 control library.

Back in the `80s, Microsoft concocted the term dynamic link library to refer to the type of file we call simply "library" in this text. Perhaps by itself, "library" wouldn't have had the raw sex appeal necessary for Microsoft to sell new gizmos such as Windows 386 (remember that old blue box?). Today, the longer term has become something of a vestigial remnant, because there really isn't any other way for one program to link with another except dynamically and there isn't any other type of program that performs this type of linking except a library. So while these files still maintain their old .DLL filename extensions, today they're basically referred to as "libraries."

A lexicon is an object's own vocabulary
Prior to 1996, the single library program that provided the functionality for the most common Windows gadgets and controls was the behemoth Microsoft Foundation Class(MFC) library. Today, MFC is on version 4.2, which spans over 32/3 MB of the WINDOWS SYSTEM subdirectory. When Microsoft began its much-touted ActiveX campaign in 1996, marking the corporation's move towards more component-based Windows programs, it began distributing a more compact (just under lMB) library, called the Forms library, for the presentation of controls to Windows.

What distinguishes today's Forms 2.0 from MFC 4.2 is that Forms controls have their own vocabulary--their own sets of properties, methods, and recognised events that make them addressable as objects through programming languages such as VBA. This vocabulary is called the lexicon of the objects that make up the library.

Form modules and the VBA workspace
The Forms 2.0 library is shipped as part of Office 97. With VBA, you can use this library to build a dialog panel based on the Forms library's UserForm class. To build the form the way you want it to appear when the VBA module is run, you drag the most common Windows controls(supplied by Forms 2.0) from the VBA toolbox onto an instance of UserForm, where they snap into place and are instantly usable.

From VBA's Properties window, you enter the initial, or default, property settings for all of the controls in the form, plus the form itself. Because each of the Forms controls, including UserForm, recognises its own events--being clicked, being double-clicked, being given the focus, losing the focus, having an item chosen from its menu--it becomes easy for you to write event procedures that define the control's behaviour in response to those events.

The various windows that make up the VBA environment can be placed anywhere within the workspace without changing their function or purpose. The Project window presents a list, in an Explorer-like "tree" format, of all the currently active projects. As you may recall, a project as VBA perceives it is any programmable component that's currently open in the workspace of the VBA environment's native application.

So for Word 97, Norma1is always one of the active projects because Normal is the name of its persistent template. Added to that, each open document has its own project in the list, and each open template upon which open documents are based has its own project.

The project window manages multiple projects
If you click the + button to the left of the word Normal in Word 97's Projects window, you'll find at least one subordinate listing for Microsoft Word Objects. Next, if you click that listing's + button, you'll find ThisDocument. In fact, anywhere else you click Microsoft Word Objects in the Projects window, you'll see ThisDocument also. Despite their identical appearance, all of these ThisDocument objects are not the same. Instead, each ThisDocument object acts as the default container for other constituent objects within their respective projects. This is important because a Forms object that's embedded within an actual Word 97 document, rather than a dialog panel, is programmed as a constituent not of UserForm but ofThisDocument.

VISUAL BASIC FOR APPLICATIONS5 BIBLE
D F Scoft
Published by Comdex Computer Publishing
Price: Rs 450 (with CD)