Datasheet

Chapter 1: A Quick Introduction to Programming

Understanding Top-Down Programming

So far in this chapter you’ve written very simple top-down style programs. The process is simple

to follow:

❑ Write some code.

❑ Save the code in a script file.

❑ Use Windows Script Host to execute the script.

❑ The Script Host starts executing at the first line and continues to the last line.

❑ If a script file contains some procedure definitions (such as your PromptUserName function),

then the Script Host only executes those procedures if some other code calls them.

❑ Once the Script Host reaches the last line of code, the lifetime of the script ends.

Top-down programs are very useful for task-oriented scripts. For example, you might write a script to

search your hard drive for all the files with the extension

.htm and copy all the names and file locations

to a file, formatted in HTML to act as a sitemap. Or you might write a script that gets executed every

time Windows starts and which randomly chooses a different desktop wallpaper bitmap file for that

session of Windows. Top-down programming is perfect for these kinds of scripts.

Understanding Event-Driven Programming

Event-driven code is different, and is useful in different contexts. As the name implies, event-driven code

only gets executed when a certain event occurs. Until the event occurs, the code won’t get executed. If a

given event does not occur during the lifetime of the script, the code associated with that event won’t be

executed at all. If an event occurs, and there’s no code associated with that event, then the event is

essentially ignored.

Event-driven programming is the predominant paradigm in Windows programming. Most of the

Windows programs you use every day were written in the event-driven model. This is because of the

graphical nature of Windows programs. In a graphical user interface (GUI), you have all sorts of buttons,

drop-down lists, fields in which to type text, and so on. For example, the word processor program

Microsoft Word is totally jam-packed with these. Every time a user clicks a button, chooses an item in a

list, or types some text into a field, an event is “raised” within the code. The person who wrote the pro-

gram may or may not have decided to write code in response to that event. However, if the program is

well written, an item such as a button for saving a file, which the user expects to have code behind it,

will indeed have code behind it.

How Top-Down and Event-Driven Work Together

When a GUI-based program starts, there is almost always some top-down style code that executes first.

This code might be used to read a setting stored in the registry, prompt the user for a name and pass-

word, load a particular file at startup or prompt to take the user through setup if this is the first time the

application has been run, and so on. Then a form typically comes up. The form contains all the menus,

buttons, lists, and fields that make up the user interface of the program. At that point, the top-down style

coding is done, and the program enters what is known as a wait state. No code is executing at this point

and the program just waits for the user to do something. From here on, it’s pretty much all about events.

c01.indd 24c01.indd 24 8/27/07 7:45:26 PM8/27/07 7:45:26 PM