Event Driven Programming

Top  Previous  Next

Related to user control issues, and the most important concept for new Windows programmers, is that you must design Windows programs to be event-driven. This means controlled by messages. In a multi-tasking environment, a program simply cannot direct the sequence of program action—the user directs it.

The underlying structure of Windows is such that the operating system informs the program with messages just what it is the user wants the program to do. This is the opposite of DOS programming.

Windows messages tell a program when a menu is selected, when a window is selected, when the user wants to shut down the operating system—the MSDN documentation devotes over 200 pages just to listing and explaining the different messages. Most programming languages require elaborate message handling procedures to branch program flow upon receiving different types of Windows messages.

Clarion automatically handles the housekeeping associated with message handling. The ACCEPT loop frees the Clarion programmer from worrying about system messages. Yet you still must consider the event-driven model when designing your program.

A Windows program must constantly look for input—in the form of data entry in an edit box, for example. In a window with several controls, the user can TAB or CLICK with the mouse to make any of them active. You must plan your input dialogs accordingly.

Additionally, your users will expect a complete set of user interface elements, including menus, multiple windows and graphical controls, all available simultaneously.

You may create an application which allows the user to open two windows, with markedly different functions. Clarion will automatically handle events generated within each window. Yet what about the menu commands, or the tool bar? You should plan these so that the commands will act on any active window. Clarion helps you do this automatically when creating an application using Multiple Document Interface. There may be times, however, when you may need to manually disable and re-enable menu commands.

Finally, the event-driven model should influence the windows you design for your application. Plan on using your main application window as the backbone for your program. Generate another window only upon some user action in the main window.

Background Processing

Background processing is another important concept for Windows programmers. In a multi-tasking environment, your program should always leave the user in control, especially when it is doing a lengthy process such as reading or writing a large file.

At the language level, Clarion supports background processing through the invocation and detection of TIMER events. That is, specifying a TIMER for a WINDOW tells the operating system to generate a timer event for the Window at regular intervals. The TIMER Events may be detected and acted upon within the WINDOW’s ACCEPT statement. Your program performs a small portion of a larger process for each timer event. The net effect is that your program can work concurrently with other programs that employ a similar technique.

 

See the Language Reference for more information on TIMER, ACCEPT, EVENT().

At the template level, all the Clarion templates automatically support background processing with the TIMER technique described above. The ABC Templates dynamically adjust records per cycle to optimize sharing of machine resources.

You can control the sharing of machine resources by adjusting the amount of time between timer events and the amount of processing that occurs for each timer event. For example, a small TIMER interval with a high volume of processing per interval hogs resources, whereas a large TIMER interval with a small volume of processing per interval lets the machine sit idle.

A reasonable TIMER interval ranges from 1/100 to 30/100 of a second depending on the process performed and the hardware doing the processing.

 

MyWindow  WINDOW(‘With a Timer’),TIMER(1) !1/100 of a second

          ...

         CODE

          ...

          MyWindow{PROP:Timer} = 30 !30/100 of a second

A reasonable number of iterations or LOOP cycles per interval may range from 1 to 1000, depending on the length of the timer interval, the process performed, and the hardware doing the processing. See the RecordsPerCycle variable generated by the Process template.