OWLNext    7.0
Borland's Object Windows Library for the modern age
Loading...
Searching...
No Matches
TCommandEnabler: The command-enabling interface

Although in command-enabling functions you always manipulate an object derived from TCommandEnabler as opposed to an actual TCommandEnabler object, in practice it appears as if you are working with a TCommandEnabler object.

TCommandEnabler provides a consistent interface for the other command-enabling classes, which implement the appropriate functionality for the type of command object that each class services.

Because you never create an instance of the TMenuItemEnabler and TButtonGadgetEnabler classes, they are declared in source files instead of header files. You don't need to be able to create one of these objects; instead you work with the basic TCommandEnabler interface, while your handler functions are ignorant of the specific command tool that is being handled.

This topic describes the TCommandEnabler function interface. There are two approaches to the TCommandEnabler function interface:

  • If you are using existing command-enabling classes, you need to be familiar with the basic interface as implemented in the TCommandEnabler class.
  • If you are deriving new command-enabling classes, you need to be familiar with the actual implementation of functionality in the TCommandEnabler base class.

This topic discusses both approaches and points out which aspects are relevant to using existing classes and which are relevant to creating new classes.

TCommandEnabler functions

TCommandEnabler has a number of member functions:

  • Because TCommandEnabler is an abstract class, its constructor is of interest only when you are deriving a new command-enabling class. The TCommandEnabler constructor takes two parameters, a uint and an HWND. The uint is the command identifier. The constructor initializes the Id data member with the value of the command identifier. The HWND is the handle to the window that received the command-enabling message. The constructor initializes HWndReceiver with the value of the HWND parameter.
  • Enable takes a single bool parameter and returns void. The bool parameter indicates whether the command should be enabled or disabled; if it 's true, the command is enabled, if it 's false, the command is disabled.
  • From the standpoint of deriving new classes, all that TCommandEnabler::Enable does is perform initialization of data members in the base class. Any other actions required for enabling or disabling a command item must be handled in the derived class. For example, TMenuItemEnabler performs all the work necessary to turn menu items on or off. Derived classes' Enable functions should always call TCommandEnabler::Enable.
  • SetText takes a single parameter, a const char far*, and returns void. This function sets the text of the command item to the string passed in the character array parameter. SetText has no effect on button gadgets.
  • SetText is declared as a pure virtual; you must declare and define SetText in classes derived from TCommandEnabler. Whatever steps are needed to implement this functionality in your command item must be done in the derived SetText function. If, as is the case in TButtonGadgetEnabler, there is no valid application for the SetText function, you can simply implement it as an empty function.
  • SetCheck takes a single int parameter and returns void. This function toggles the command item on or off, depending on the value of the int parameter. This parameter can be one of three enumerated values defined in the TCommandEnabler class, Unchecked, Checked, or Indeterminate. Unchecked sets the state of the command item to be unchecked, Checked sets the state of the command item to be checked, and Indeterminate sets the command item to its indeterminate state. The nature of the indeterminate state is defined by the command item:
  • For menu items, the indeterminate state is the same as unchecked.
  • For button gadgets, the indeterminate state is an intermediate state between checked and unchecked. SetCheck is declared as a pure virtual; you must declare and define SetCheck in classes derived from TCommandEnabler. Whatever steps are needed to implement this functionality in your command item must be done in the derived SetCheck function.
  • GetHandled takes no parameters and returns bool. This function returns true if the command enabler has been handled by calling the Enable function. Otherwise, it returns false.
  • IsReceiver takes a single HWND parameter and returns a bool value. IsReceiver returns true if the HWND parameter matches the receiver HWND passed into the TCommandEnabler constructor and stored in HWndReceiver. Otherwise, it returns false.

TCommandEnable data members

TCommandEnabler contains three data members:

  • Id is the only public data member. This member contains the identifier for the command. It is declared as a const uint and is initialized in the constructor. Once initialized, it cannot be modified.
  • HWndReceiver contains the handle of the window that implements the command. This is a protected data member and cannot be directly accessed unless you are deriving a class from TCommandEnabler. HWndReceiver can be accessed indirectly by calling the IsReceiver function, which compares the value of the HWND parameter passed in to the value of HWndReceiver.
  • Handled indicates whether the command-enabling object has been dealt with. It is initialized to false in the TCommandEnabler constructor and set to true in TCommandEnabler::Enable. This is a protected data member and cannot be directly accessed unless you are deriving a class from TCommandEnabler. Handled can be accessed indirectly by calling the GetHandled function, which returns the value of Handled.