The concept behind 'event driven programming' is not as easy to explain as programming for Windows.

You can explain the Windows programming by simply saying, "Wow! ow ! can create programs in "ust a few minutes without #nowing a thing about $%%." &ne problem is that the core idea is "ust too simple to seem that important. 'ere it is( Your )* program doesn't 'do' anything except sit there and wait for 'an event'. Then it does different things depending on what the event is. Which event+ That's up to you, the programmer. What does it do+ That's up to you too. ,et's put this in pictures. 'ere's what happens when a typical )* program is started.

-o what good is this+ This is the magic ingredient that ma#es the program 'interactive'. The form and buttons displayed on the computer screen is part of what is called a ./!, or .raphic /ser !nterface. That simply means that the pictures on the screen interact with the mouse, #eyboard, or maybe even something else. !n the case of a touch screen, it might be your finger. ow, the program can do one thing when a user clic#s button '0' and something completely different when button '*' is

clic#ed. The 'event' is that one or the other button is clic#ed. Your program code is in little chun#s called 'event code'. ,et's loo# at an example of event code. 1ach button is an 'ob"ect' in programming terms and has a name that you, the programmer, can control. We'll use the name '$ommand0' for button '0' and '$ommand*' for button '*'. -uppose we wanted to simply display a message stating which button was clic#ed. 'ere's the code that would do the tric#.

The idea now is simply to understand the relationship between 'ob"ects', 'event code', and your program. )isual *asic helps you create a visual interface, called a ./! and helps you enter event code that interacts with the ob"ects. We'll actually program this example.