Visual Basic's Event Driven approach is very different!
See if this doesn't help to clear up the problems.
If it doesn't help you then let me know so I can do whatever is necessary to make it understandable.
Paul Lecoq
Look closely at the image to the right and the prompt image on the left.They don't make sense, do they? In fact, they are optical illusions but perhaps their obtuseness will help to understand what Visual Basic is all about.
The old way: In-Line programming
Even in-line programming can be a problem understanding but it is as simple
as it gets. Basically, an in-line program starts at the top and cranks line-by
line, statement by statement until it gets to the bottom. Each statement
executes after the previous one, each statement does something to the data.
Early on, things are input to the data base. the program proceeds to process
it, to modify it, to draw conclusions from it. Finally, towards the bottom
of the program the fully processed data is produced either on-screen or printed
out. In line programs don't just move from start to finish, though. Decisions made throughout the program cause alternate paths to be taken, depending on conditions. For example, the if-then paths you see in the rough road map over on the left of the page says that, depending on a particular condition, the program will either do some extra process or, if the decision is false, then that extra process is not done. This is a simple binary or two way choice. If some condition is true, then do some extra processing, if it isn't true, then don't do that special processing. You can follow the alternate paths in the crude road map. An example illustrates. The decision might be based upon whether a student has paid tuition yet or not. If it has been paid, the program bypasses the tuition collection process. If fees haven't been paid, then the tuition collection process is performed.
A decision may be more sophisticated. In the If then else decision, the program must decide based upon a particular condition whether to do the processing in one way or another. This is indicated by the If then else mapping. If the condition on which the decision is made is true, we follow the right hand path. If the decision is false, the program takes the left hand path and does the processing called for on the left path. An example might be whether to process student registration for returning students on the right and new students on the left.
A very different kind of decision is a loop. Basically, this says to do something repeatedly until some condition is satisfied. An example might be the processing of all of a student's classes. The program has to go through the assignment process repeatedly, once for each class the student wants to take. the loop continues until the student indicates that there are no more classes in which he chooses to register.
At various places within the program, it may request interaction from the user by displaying some kind of a message and waiting for an input. Even in these cases, though, the program will continue after the input right from the place where the pause occurred.
The bottom line for an in-line program is that it starts at the top and moves to the bottom step by step. Progress may be delayed by a request for user input or may be interrupted by an if or a loop but from the time the program is started until the program ends it is following a single thread of operation as defined by the statements written by the programmer. An in-line program is inherently much simpler than an event oriented program.
Event oriented programs: Think of it as many in-line programs, each attached to something called an object.
The complexity of the event driven program comes from the fact that it is a whole bunch of in-line programs, each of which may be executed under varying conditions. As the drawing below illustrates, the user is presented with many choices on the active form. The choices vary from text boxes to list boxes to just about anything that programmers can think of.
It just isn't easy to imagine all the possible combinations of options from which the user can choose. It is the programmer's job to present these objects, in other words, the choices to the user in such a way that the user can figure out how to run the program correctly. That's not an easy job.
It's also not easy for the programmer to juggle all the possibilities around and figure out how to use each of the objects. Then it is even more difficult to write the in-line programs for each of the objects to make them interact properly. Let's look at the illustration to the left.
The user is presented with a series of graphic "things" on the form. If they are properly designed and labeled, the user can figure out what happens when each of them is activated. He might use the upper left object, the oval, to look inside the program's variables to see what is available. Note the loop which enables him to go through all the data.
He sees something he likes so he chooses the upper left object to insert his own information into the program's data base. Note this is a simple in and out program.
He uses the lower left object to choose between a few chunks of data to extract the five or six things he wants from the data base.
If he is satisfied and chooses to, the user can select the lower right object to cause a final report to be generated.
Note that the user could conceivably do these in any order. It is up to the programmer to see to it that the user can't do things that will cause the system to crash. For example, it might be that the lower right object would put out garbage unless the lower left object were exercised first. In that case, the lower right object should not be enabled until the lower left object has run.
The complication is that the event driven program gives the user so much flexibility that the programmer has to design them well enough to be "user friendly".
The steps used to create a good event driven program.
The first step is to figure out exactly what it is you are going to do. What does the program have to accomplish? Typically this involves a lot of interaction with the ultimate user.Second: You build a user interface by placing form(s) in the program and objects on the form(s). You take great care in laying out the screens to make them as user friendly as possible. Before you proceed you will generally have to go over the user interface with your client. Chances are, you will have to change the user interface to meet your client's needs.
At this point you will have pretended to be the computer walking through the objects on the forms to make sure they will do exactly what they are supposed to.
The third step is the heart of the design. For each of the objects which must react to user input, you design an in-line program to do what the user expects it to do.
My approach to this problem is to write clear English statements as remarks in the code window
for each of the objects which has to respond to user inputs. Using English instead of BASIC in the design process makes it easier to figure out exactly
what has to happen in the in-line program attached to each object on the form.
As you can see in the example on the right, a sub for the command button
cmdX, the comments define the job to be done whenever this button is clicked.The first remark is a general description of what this routine is supposed to do.
Note that not all the details are here. This button's design should correlate with the other objects in the program. In this case, a personnel file exists which this program has to access.
We may have to add more remarks to this task unless it is very clear where the personnel file is and how we can get into it. In this case, the personnel file has been opened by the "OPEN PERSONNEL FILE" button. All we have to do is to look for the person's name in the file. That determines the string that we will be working on later in the Sub. Note that these things progress sequentially as in any in-line program.
Once the name has been found, the next task is to extract the name field. The three blue lines describe how that is to be done ---- IN ENGLISH.
Having extracted the name, the next three blue lines extract the other field, the age.
the last line finishes the job by adding the name and age to the list box. Does this program care what happens to the list box? No! It's job is to extract something from a personnel file and put it into the list box. That's it.
Note that the emphasis at this stage is to describe the steps to be followed by the program once it is written. We leave the details of the algorithm to the time when the code is written. The design in English defines what is supposed to happen when this button is clicked. We do the same kind of thing for all the objects which have to respond to user input. Of course, before we proceed, we always walk through the English comments to make sure that they call for exactly what has to be done.
Remember: We write the code wherever the event takes place. This code isn't for the list box or for the personnel file. It responds to a click on this box.
When it comes time to code, we can be sure that the design is largely correct. The coding task should be relatively simple. We dim the variables we may need, we then translate each line of English comment into Basic code. If we find that we have to change too much of the English code, it means that we haven't done the design thoroughly enough.
Debug and testing follow coding. More about them later.
Relationship between objects and the code:
The drawing below illustrates an important relationship:
Note that some of the objects have code associated with them while others
don't. The option box and check box in this sketch affect the code of other
objects but don't need any code themselves. The objects as executed by the user affect the data base of the program and control what kind of information is delivered to the output. The first generic object, the oval has code written for it that appears to make a decision based upon the option button. If the program takes the upper path it does some things and goes on to affect the data. If the lower path is taken, the process is obviously more complex as we can see from the loop in the lower path.
The weirdly shaped object also has code attached. It first uses the option button to make a decision. The upper path, the simpler one is chosen if the option button signifies yes. The lower "no" path proceeds, needing the check box to determine another branch. The program branches either to "checked" or to the " not checked" process. Either way, the program proceeds to its end.
Design pseudocode (in other words, English) for the weirdly shaped might look something like this:
'The purpose of this module is ~@$%%^^&&^$#@@@!!!!!!!#%^^
'
'Do this first task whatever it is
'Do this second task whatever IT is
'Use the option button to make a decision
'If the option button says yes --- a decision question
'The option button said yes so do this stuff here
'do this other stuff on this path
'else in other words, if the button doesn't say yes
'The option button said no so do this stuff down here
'more stuff to be done on this path down here
'Use the check box to make this decision
'IF the box is checked,
'do this stuff
'else
"The box isn't checked so do that stuff
'Do this nearly last task
'Do this last task to print the report and quit.
'End of program for this object
Note again that the code is written for the objects at which the changes
are felt, not at passive objects. However, passive objects' state can affect
the operation of code written for other objects. Each of the objects which
need code are coded as in-line code, independent of other objects' code.
The objects can interact but only by using variables or properties of objects
in making decisions.
So what the heck am I getting at here?
Event driven programs are much more complicated than in line programs because
they aren't just in-line. In fact most event driven programs are collections
of many in-line programs all bundled together by a protocol, that is, they
are bound together by designing and coding them all together in such a way
that they work together.
Indeed it is more difficult to program many in-line
programs than to program one in-line program.
Paul Lecoq