Event and Action Mapping

In a typical user interface, a user can request a specific action in many different ways. For example, in the example application, a user can close the application by

Each of these choices creates a different user interface "event". For example, the first two produce a "click" event on different menu items. The third and fourth events are "accelerator" events. The last is a click on a push button. The code that handles the main application window can be programmed to react to each of these events. The code is identical for each case, since each of these events is another way to tell the main application window to "exit the application". That is, "exit the application" is the "action" that the user is requesting the main application window to take.

The Framework provides support for event to action mapping through a table (called EventAction) that maps user interface events to action names. A program, pGetAction, can be called to do a FORM INPUT and translate the user interface event into an action name. This enables window management programs to be written to handle actions rather than specific user interface events and greatly simplifies the code.



The example application code in Using the Framework - Examples (beginning with Simple Event Loop and Main Windows) illustrates the usefulness of mapping different interface events to a common action name. It is very common to provide users with different ways to invoke the same action. For example, it is not uncommon to enable an action to be invoked by selecting a specific menu item, by pressing an accelerator key, and by clicking on a push button. Application code can be greatly simplified if it only needs to respond to unique actions without being concerned about how those actions were invoked.

The Framework supports event/action mapping through

Each of these is described briefly below. For more information, see the Reference Guide.


EventAction is an EntitySet defined in $DeployServices. Each Zim database has its own copy of EventAction. The main fields of EventAction are WindowTag, ObjectTag, EventType, EventName, Action, Macro, Comment, and EventActionOwner.


pGetAction is called to get the next action. It is integrated with the Message Queue. If any actions are on the Message Queue, the next action on the queue is returned. If the Message Queue is empty, pGetAction does a FORM INPUT and reads EventAction to map the user interface event to an action.

Standard Event/Action Mapping

The standard contents of EventAction provide predefined event to action mappings.

In effect, by attaching one of these tags to a menu item, the indicated callback is automatically called when you select that menu item. All of these mappings tend to enforce consistent usage in different applications.