OWL Tutorial - Step 2

Menus and Event Handling

Date: 19 March 1997
Author: Christopher Kohlhoff

The architecture of the Windows interface is based heavily on the concept of an event. An event is sent to an application (or window) when the user performs an action (such as clicking the mouse or selecting a menu item), and in response to system actions.

In programs using the raw Windows API (that is, not using a framework such as OWL) event handling usually involves enormous switch/case statements. Fortunately OWL provides a much simpler mechanism: the response table.

Adding a Menu

In order to see event handling in action, we will add a menu to the application. Menus are one of the most common ways of adding interaction to an application. To add a menu, do the following:

Defining a Response Table

Now that we have added a menu to the application, we want to handle events, such as responding to the user selecting a menu item. To handle these events we must add response tables to the window and application.

We will add a response table to TTutorialClientWindow so that we can respond when the user clicks and moves the mouse:

We will now modify the TTutorialApp class to display a message box when the user selects Help|About. We will also make it so that only one shape (Line, Rectangle or Ellipse) can be selected, and that selection will be indicated by a check against the menu item.

Command Enabling

When you compile and run this application, you will note that all of the menu items are greyed out except for File|Exit and Help|About. What these both have in common is that there are functions that resond to them (File|Exit is handled by the TApplication class). But how does OWL know to grey the other items out? And when is the CeShapeSelect function called?

OWL uses a process called Command Enabling. Basically it works by performing the following steps for each menu item when a menu is about to appear, and when the application is doing nothing. Note that this explanation is much simpler than what actually happens.

The need to be able to call a base class's response table is why the DEFINE_RESPONSE_TABLEx macro can take more than one parameter. If we were to change the line
 DEFINE_RESPONSE_TABLE1(TTutorialApp, TApplication)
to be
 DEFINE_RESPONSE_TABLE(TTutorialApp)
the menu item File|Exit would no longer be enabled (try it!).

The command enabling sequence above has the additional feature that if we add our own CmExit to TTutorialApp and add the line
  EV_COMMAND(CM_EXIT, CmExit),
to the response table, then TTutorialApp::CmExit would be called, but TApplication::CmExit would not. This allows us to override the event-handling functionality of base classes.

 

Previous Step | Next Step | Tutorial Contents