< Continued from page 2
What does it mean when we say that Visual Basic an "event driven" language? One way to understand this is to look back at the way things used to be (and sometimes, still are) using purely 'procedural' languages.
The original Basic language let you write programs that started, did something, and quit again. So, for example, if you were going to update a customer accounts file with the day's business, a program could start, open a file or database with customer accounts and another one with transactions for the day's business, match transactions against accounts and perform the update, then close the files again.
Job Done! The only problem is that they all had to be done together in a "batch". That's why this kind of program was called, "batch processing". If you're old enough, you probably heard the excuse, "Oh ... the files won't be updated until the end of the month." That's batch processing.
Certainly, that kind of processing is still done, but in the online, realtime era of computing today, it's much more common to see systems that update a customer account just as soon as the business is done! Even waiting until the end of the day is just not good enough. For that kind of performance, you have to have systems that start a program to perform the update as the result of an event - in this case, probably when someone clicks a button that says, "Buy This!"
Event driven programs are already started and are just sitting in a computer's memory waiting for an event that they recognize as 'their job' to happen. When it does, they spring into action and do it, then go back to waiting for the next event.
How all this magic happens is a deeper level of programming that involves the way Visual Basic interacts with the Operating System. For now, it's enough to recognize that it does happen and that there is a whole universe of events that you, the programmer, can use in your programming code.
The event that we're going to use in our Form Letter program to kick off the substitution of text into the document is the Click event of a CommandButton object.
Make sure your Form Letter document and the Visual Basic Editor are still open. The UserForm you created earlier should be visible.
Either the program code or the form is visible in the Visual Basic editor. I find that the easiest way to switch between them is to right click the UserForm in Project Explorer and select either View Code or View Object.
Now double click the CommandButton object on the Form. This should open the code window with your event subroutine already started for you.
In Visual Basic, event procedures are named in a very specific way to tie objects and events together. When a particular object raises a particular event, Visual Basic looks for a subroutine with the standardized name ObjectName_EventName. If it finds one, that subroutine is started.
Click the down arrows on both the Procedure Box and the Object Box and see what else is available. For example, if I wanted something to be done after updating the TextBox txtBook, then I would write some code in the txtBook_AfterUpdate() subroutine.
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
What code should we write in our event subroutine? In fact, most of it has already been written and it's in the AboutFormLetter subroutine in Module1. Using the 'looping code' that was written earlier (primarily because it makes a better illustration!), we have to make exactly one change to get the program to use the value from the TextBoxrather than being 'hard coded':
Replace the statement:
NewDoc = NewDoc & "Mr. Publisher Dude"
With the statement:
NewDoc = NewDoc & txtName.Text
A similar replacement would have to be coded for the txtBook field.
For a more complete program, the result of the text substitution also has to replace the entire current document. This statement just after the Next Searchword statement will do the trick: ActiveDocument.Content = NewDoc. In addition, as it stands, the Visual Basic editor has to be opened to run the macro. It would be a lot more 'user friendly' to Show the UserForm when the document is opened. This subroutine in the Open event for ThisDocument will do the job:
Private Sub Document_Open()
UserForm1.Show
End Sub
What does it mean when we say that Visual Basic an "event driven" language? One way to understand this is to look back at the way things used to be (and sometimes, still are) using purely 'procedural' languages.
The original Basic language let you write programs that started, did something, and quit again. So, for example, if you were going to update a customer accounts file with the day's business, a program could start, open a file or database with customer accounts and another one with transactions for the day's business, match transactions against accounts and perform the update, then close the files again.
Job Done! The only problem is that they all had to be done together in a "batch". That's why this kind of program was called, "batch processing". If you're old enough, you probably heard the excuse, "Oh ... the files won't be updated until the end of the month." That's batch processing.
Certainly, that kind of processing is still done, but in the online, realtime era of computing today, it's much more common to see systems that update a customer account just as soon as the business is done! Even waiting until the end of the day is just not good enough. For that kind of performance, you have to have systems that start a program to perform the update as the result of an event - in this case, probably when someone clicks a button that says, "Buy This!"
Event driven programs are already started and are just sitting in a computer's memory waiting for an event that they recognize as 'their job' to happen. When it does, they spring into action and do it, then go back to waiting for the next event.
How all this magic happens is a deeper level of programming that involves the way Visual Basic interacts with the Operating System. For now, it's enough to recognize that it does happen and that there is a whole universe of events that you, the programmer, can use in your programming code.
The event that we're going to use in our Form Letter program to kick off the substitution of text into the document is the Click event of a CommandButton object.
Make sure your Form Letter document and the Visual Basic Editor are still open. The UserForm you created earlier should be visible.
Either the program code or the form is visible in the Visual Basic editor. I find that the easiest way to switch between them is to right click the UserForm in Project Explorer and select either View Code or View Object.
Now double click the CommandButton object on the Form. This should open the code window with your event subroutine already started for you.
In Visual Basic, event procedures are named in a very specific way to tie objects and events together. When a particular object raises a particular event, Visual Basic looks for a subroutine with the standardized name ObjectName_EventName. If it finds one, that subroutine is started.
Click the down arrows on both the Procedure Box and the Object Box and see what else is available. For example, if I wanted something to be done after updating the TextBox txtBook, then I would write some code in the txtBook_AfterUpdate() subroutine.
--------
Click Here to display the illustration
Click the Back button on your browser to return
--------
What code should we write in our event subroutine? In fact, most of it has already been written and it's in the AboutFormLetter subroutine in Module1. Using the 'looping code' that was written earlier (primarily because it makes a better illustration!), we have to make exactly one change to get the program to use the value from the TextBoxrather than being 'hard coded':
Replace the statement:
NewDoc = NewDoc & "Mr. Publisher Dude"
With the statement:
NewDoc = NewDoc & txtName.Text
A similar replacement would have to be coded for the txtBook field.
For a more complete program, the result of the text substitution also has to replace the entire current document. This statement just after the Next Searchword statement will do the trick: ActiveDocument.Content = NewDoc. In addition, as it stands, the Visual Basic editor has to be opened to run the macro. It would be a lot more 'user friendly' to Show the UserForm when the document is opened. This subroutine in the Open event for ThisDocument will do the job:
Private Sub Document_Open()
UserForm1.Show
End Sub
SHARE
