Event-driven environments

Ever gone on a treasure hunt? You know the sort of thing - you all start off with the family in the car from a given point. You have a set of clues which you can follow in pretty much any order and you must all end up at the place indicated by those clues. Usually, a barbeque ensues - quite often family arguments, divorce and separation, too, particularly if the weather is hot. DOS programming is a bit like that. We start our program at the top and we go down the statements (the clues) one by one but there are points when we can make decisions - will we go this way or that way? In assembler, we implement these decisions with the "Jump" statements, something we will deal with in its own chapter. In concept, however, it's very simple. The point is that there are only so many ways in which you can get from start to finish, as you can see from the illustration, and they were all known to the programmer when he wrote the code. In Windows, however, things are little more fluid.

The Windows operating system is a good example of an event-driven environment but what exactly does that mean? I always try to relate computer concepts to parts of the body if I have to explain it to someone. Your brain sits on top of your spine and responds to stimuli from the outside world. For example, a noise occurs and the sound waves hit your ears, get transformed into electrical impulses and are then fed into the centre of hearing via the auditory nerve. When that happens, the brain processes the sound to see if it can make sense of it and to decide if it needs to do something as a result. The stimulus (the sound, in this case) is the event and the processing done in the brain as a result of the sound is the event handler. The important thing to note is that the centre of sight is not affected by the sound, nor is the area for processing the sense of touch. Only that part of the brain responsible for dealing with sound is immediately affected. So, we must determine which events we are interested in (and there are many to choose from) and to write a handler for each. If we are not interested in a particular event in this particular program, we simply ignore it completely. Dealing with messages appropriately is an important task, for your Windows program would be very boring indeed if it could not react to user handling. And that’s the reason for our declaring the messages and their associated handlers right up there in the .Data section of our assembler script. In the next chapter, we’ll see how to set up data items to hold other types of information than just messages.

OK, so how does our program deal with these messages? Inside Windows, it’s just like a brain being bombarded with all the sensations of the outside world. There are messages flying everywhere. Our program has to be able to “hear” these messages but it needs to react only to those ones for which we have stated an interest and for which we have bits of code (the event handlers) to deal with them. That means we have to examine the first message to arrive, check if it’s one of the ones in our list (WM_CREATE, WM_CLOSE) and, if it is, to jump to that bit of the code we have declared is waiting to handle it (OnCreate, OnClose) and then come back to wait for the next message. If it is not one of these messages, our code should simply throw it away and then go and get the next message from the queue waiting for processing. This is called the event processing loop. If you look in the .Code section of the program, you’ll see something called winMainProcedure. This is the event processing loop for your main window and performs the actions pretty much as described above. We’ll look at the commands (the mnemonics) in more detail in subsequent chapters.

Below the processing loop, you’ll see the two event handlers – OnCreate and OnClose. The names as fairly self-explanatory. The first is activated when the operating system notices that the window has been created and the second when the window is being closed down. You can call these handlers anything you want. For example, you could change “OnCreate” to “Startup”, for example, as long as you remember to do the same in the Data section. But these are sensible names and you should name your own handlers along these lines.

You’ll notice that the OnCreate handler doesn’t really do anything. It just “returns” to the main event loop. But the OnClose handler has some work to do and asks the operating system to close your main window down gracefully: