In traditional procedural programming, the application starts (typically in a procedure named "Main") and from that point onward has complete responsibility for everything that happens. It must handle keyboad input, mouse input, output to the screen, etc. With Visual Basic (and Windows in general), you no longer need to worry about low level input handling. Windows and Visual Basic take care of the details for you, allowing you to concentrate on what the application is supposed to accomplish.
Lets say for example that you want a program to display a message when the user clicks on a button. With a DOS based program, you would need to track the mouse position, display a cursor, detect the mouse click, redraw the button when its clicked, and display the message. Visual Basic and Windows greatly simplify this process. To accomplish the same task, you simply draw a command button on a form, and write a procedure to handle the click event. VB and Windows will take care of the mouse and fire the event when the user clicks on the button. All you need to do is attach the code to the button's click event and write the code that you wish to run when it occurs.
To add an event procedure and attach it a form or control, just pick the form or control
from the "Object" combo box in the code window and choose the event from the "Proc"
VB will create the event procedure for you in the code window. All that's left for you to do is to add the code that you wish to run when the event is fired by VB. Here's the result of our attempt to display a message.
Private Sub cmd_Click() MsgBox "Hello World!" End SubWhen the user clicks on the button "cmd", the message box will be displayed. That's all there is to it. Once you understand this simple - but not entirely obvious - concept, you're ready to start writing code for your VB applications.
To demonstrate form events, I created a new form and placed code like this in the event procedure for each of the events:
Private Sub Form_Load() Debug.Print "Load" End SubFor each event, the name of the event was sent to the debug window. Here was the output:
Initialize Load Resize Activate Paint ' I closed the form here QueryUnload Unload TerminateThere are other form events also, such as the click event, etc., but those must be triggered by user actions or other code. These are the events that are always triggered for forms and the generic order in which they occur. Let's take a look at each.
Unload Form1 Set Form1 = NothingThe first statement will cause the QueryUnload and the Unload events to fire, but only by using the second statement can you force the Terminate event to fire. If you have form level variables, the values will not be reset after the Unload event has fired. They are only reset after the Terminate event fires and the form is completely removed from memory.
Some other common control events are Change, which occurs when the data in a control is changed, GotFocus and LostFocus, which occur when the user enters or leaves the control using the mouse or keyboard, and the Link... events, which are used for DDE operations.
Among all the control events, the one which is used most often in applications is the click event - normally attached to command button controls and menu controls.
On the other hand, if you've ever had to write a form level keyboard handler in Access, you'll find the Visual Basic KeyPreview property for forms will greatly simplify your efforts.