OWLNext 7.0
Borland's Object Windows Library for the modern age
|
The basic idea behind command enabling is that the decision to enable or disable a function should be made by the object that handles the command.
ObjectWindows does this by sending the WM_COMMAND_ENABLE message through the same command chain as a WM_COMMAND event. The event is then received by the window that implements the functionality that you are enabling or disabling. When a WM_COMMAND_ENABLE message is sent depends on the type of command item that is affected. TFrameWindow performs command enabling for menu items when the user clicks a menu, spawning a WM_INITMENUPOPUP message. Gadget windows perform command enabling for control bar buttons during the window's idle processing.
To handle command-enabling messages for a particular function,
Suppose you have a frame window class that handles a File|Save menu command that uses the command identifier CM_FILESAVE. The class definition would look something like this:
If you did not want the user to be able to access the File|Save command if the file had not been modified since it was opened or last saved, you could add a handler function and response table macro to affect the CmFileSave function like this:
Notice that the EV_COMMAND macro and the EV_COMMAND_ENABLE macro both use the same command identifier. Often a single function can be accessed through multiple means. For example, many applications let you open a file through a menu item and also through a button on the control bar. Command enabling in ObjectWindows lets you use a single, common identifier to do command enabling for all means of accessing a function, making it unnecessary to write separate command-enabling functions for each different command item.