ON EXIT BAR, ON EXIT MENU, ON EXIT PAD, ON EXIT POPUP

We have to thank the designers of dBASE for these cool commands. According to Help, they’re in FoxPro only for dBASE compatibility. Like many of the other so-called compatibility commands, these actually do something useful.

Each command sets up an event handler for the specified item that fires when you leave that item. Like other menu event handlers, these propagate downward to fire when an item doesn’t have its own handler.

Usage

ON EXIT BAR | PAD ItemName OF ContainerName [ Command ]
ON EXIT MENU | POPUP ItemName [ Command ]

These events behave differently on the system menu than they do in user-defined menus. In a user-defined menu, once an item gets focus its ON EXIT event fires as soon as it loses focus. We can think of situations where this would let us keep track of what’s going on as a user works his way through, say, a right-click menu.

In the system menu, the events fire after the user chooses an item at the lowest level of the menu, but before the code associated with that item executes. For any given menu choice, no matter how deep it is in the menu hierarchy, no more than two of these events fire—the one for the menu pad and the one for either the actual menu bar chosen or the popup containing that menu bar.

If a bar doesn’t have an ON EXIT event, the ON EXIT event for the popup that contains it fires instead. If neither the bar nor the popup has an ON EXIT defined, only the pad’s event fires.

We can’t find anything that fires the ON EXIT event for the menu itself.

Since these fire before the code associated with the item, why do we care? Why not just do whatever it is in the code for the item?

We can think of at least one case where these events make things much simpler. Many folks like to have the menu reopen to the last choice after it finishes processing that choice. The simplest way to do this is to KEYBOARD all the hot keys that get you there, but setting up the KEYBOARD command is something of a pain. ON EXIT BAR is the perfect place to fill a global variable or an application property with the series of keystrokes needed. Then, a single command (KEYBOARD oApp.cStrokes) can reopen the menu for every choice.

Best of all would be to not have to change the saved keystrokes when the menu changes. The best hope for automating this process is a driver for GenMenuX (a tool that wraps around the menu-generation program and gives you the opportunity to change things—see “Back o’ da Book” for more info). The driver could go through the MNX and figure out the appropriate keystrokes to save, then generate the ON EXIT BAR commands as part of the menu cleanup code. Let us know if you write one.

Realize, however, that this is a nonstandard way of using menus in Windows, and may cause some of your users to feel your app is somewhat more questionable or amateurish.

Example

ON EXIT BAR 1 OF MyPopup WAIT WINDOW "You chose Bar 1"

See Also

Define Menu, On Bar, On Pad, On Selection Bar, On Selection Menu, On Selection Pad, On Selection Popup