The structure of a VisualBasic application
An application is really nothing more than a set of instructions that direct a computer to complete a task. The structure of an application is the way instructions are organized, that is, where instructions are stored and the order in which they are executed.
Typical helloworld examples and simple applications like this have a simple structure. For a single line of code, organization isn't very important. But the more complex the application, the more obvious the organizational or structural requirements are. Just imagine the chaos that would result if applications were allowed to execute in random order. In addition to controlling the execution of an application, structure also plays an important role in how to easily find specific instructions in the application.
Because Visual Basic applications are object-based, the application's code structure is a model of the program's physical representation on the screen. By definition, objects contain data and code. The form you see on the screen represents the properties that define the form's appearance and underlying characteristics. Each form in the application has an associated form module (file extension .frm) that contains its code.
Each form module contains event procedures, which are sections of code that contain instructions that are executed in response to specific events. Forms can contain controls. In the form module, there is a corresponding set of event procedures for each control on the form. In addition to event procedures, a form module can contain generic procedures that respond to calls from any event procedure.
Code that is not related to a specific form or control can be placed in another type of module—a standard module (file extension .BAS). A procedure may be used to respond to events in several different objects. This procedure should be placed in a standard module rather than repeating the same code in the event procedure of each object.
Use class modules (file extension .CLS) to create objects that can be called by procedures within the application. A standard module contains only code, while a class module contains both code and data and can be considered a control without a physical representation.
Chapter 4, "Project Management," describes which components can be added to the application. This chapter will explain how to write code into the various components that make up the application. By default, the project contains a unique form module. Additional forms, classes, and standard modules can be added as needed. Chapter 9, "Programming with Objects," discusses class modules.
How event-driven applications work
Events are actions recognized by a form or control. Event-driven applications execute Basic code in response to events. Each form and control in Visual Basic has a predefined set of events. If one of these events occurs and there is code in the associated event procedure, Visual Basic calls that code.
Although objects in Visual Basic automatically recognize a predefined set of events, it is the responsibility of the programmer to determine whether and how they respond to specific events. A code section (i.e. event procedure) corresponds to each event. When you want the control to respond to an event, write the code into the event process of the event.
There are many types of events recognized by objects, but most types are common to most controls. For example, most objects recognize the Click event—if you click a form, the code in the form's Click event procedure is executed; if a command button is clicked, the code in the command button's Click event procedure is executed. The actual code in each case is almost completely different.
Here is a typical sequence of events in an event-driven application:
1. Start the application, load and display the form.
2. The form (or a control on the form) receives the event. Events can be triggered by the user (such as keyboard operations), by the system (such as timer events), or indirectly by code (such as the Load event when the code loads the form).
3. If code exists during the corresponding event, execute the code.
4. The application waits for the next event.
Note that many events occur along with other events. For example, when the DblClick event occurs, the MouseDown, MouseUp, and Click events also occur.
->