LHAPI Messaging

The application communicates to its windows by sending them messages. Messages cover all aspects of window management: creation, destruction, changing the focus (the window the user is currently interacting with), keyboard input, and display. Usually, a message chain is initiated by the System Manager sending the application an event. This may be an activation event, or the user typing a key. This message is in turn passed to one or some windows. Those windows may in turn call other windows, or may subclass the message to allow other handlers to function on that same window.

For the most part, you don't need to worry about this messaging while writing LHAPI window handlers; just handle the messages you need to. You cannot do this, however, in a vacuum. When writing a window handler (especially one that subclasses an existing class' behavior), keep these things in mind:

• How does the class interact with its subclass? Are there certain messages that are necessary to prevent sending to the subclass? Depending on what you are trying to accomplish, you may need to parcel the message off to the subclass, and then handle it, rather than trying to make it work the other way around. Are there cases that you might not be handling? A common one is subclassing KEYSTROKE, but forgetting that the user can paste into the field. Some of the LHAPI classes do not always send themselves messages when DRAWing--you may need to trap messages (e.g. KEYSTROKE) in addition to the obvious ones in order to make the control behave properly.
• How does the class interact with its parents or children? A dialog box CREATEs itself, then all its children; it DESTROYs all its children before it destroys itself. Does this make a difference for your control that is subclassing CREATE or DESTROY? RadioButtons require their parent be a Group Box to properly handle messages. Similarly, most other controls require their parent directly be the dialog box, even if they are inside a group box. Since Object sends many unhandled messages to the window's parent window, these relationships can become important.
• Does the class interact with other windows on the screen? A combo box communicates with a listbox that is "attached" by pointing the Menu field at the list. These two windows send each other messages to keep the other up to date. In a FileOpenDialogBox, the dialog is communicating with the edit, directory and file lists, which are communicating with each other. In situations like these, subclassing needs to be thought out carefully. Try to make the least amount of impact on the messages flying through the class as you can.
• Is the inter-window messaging very deep (i.e. could you possibly run out of stack)? In deeply nested complex dialog boxes, you may be using up much more stack space than you are aware of, with all the messages being sent from window to window. LHAPI messages must be handled before they return to the caller: they are not queued. This means that if five windows send cascaded messages to each other, there will be at least five message stack frames on the stack at the deepest window. It doesn't pay to be stingy with stack space in a LHAPI application. You may wish to check validity of variables high up in your data space during operation of complex dialogs before you're done testing your application.