Content-Length: 10072 Content-Type: text/html Subclassing and Superclassing

Subclassing and Superclassing

PM provides two simple (though loose and not very formalized) mechanisms for inheritance with window classes, called subclassing and superclassing. If I want to have a button that acts just slightly different than the standard push button, it makes more sense for me to try to just affect the behavior that I want to change and let the other functionality be handled as it was before. Actually, in this case, I could possibly make it a user-drawn button but that is a special case as it only affects visual behavior, and muddies the waters of this discussion for the moment so pretend it does not exist. Let's say that I need a way to affect just the click of button 2 so that it pops up a help screen for that button, so really all I want to do is change what a button2 click does.

Subclassing

Since almost all stimuli that affect a window come in the form of messages, if you can get the messages to come to you first, you can handle the ones you want and pass the others on to the original recipient, letting him/her handle them as before. The simplest mechanism for doing this is to subclass the window, via the WinSubclassWindow() API. You pass the window handle of the window you want to subclass, and a new window procedure. PM makes your new window procedure the new recipient of all messages coming to that window. It also returns to you the address of the previous window procedure, so you can pass any unneeded messages on to the original procedure. Actually you have a number of options:

Handle the message and return without letting the original see it
Provide some preprocessing, then pass it onto the original
Let the original handle it first, then provide some post processing
Let it go straight to the original window procedure.

As far as I know, the window procedure to which a window's messages go is always stored in the QWL_PFNWP window words, so most likely all WinSubclassWindow() does is get the current value out, put the new one in, and return the old one. So you could easily do this operation yourself if you chose to do so. When a window is first created, this value is set by looking up the window class passed to WinCreateWindow() and getting out the window procedure given when the window class was registered via WinRegisterClass().

Now we can provide the special processing for the button by trapping WM_BUTTON2DOWN and WM_BUTTON2UP and doing our special processing on the up event. In this case we would not pass them on to the original since we don't want it to take its default action of posting a WM_COMMAND to its owner.

Dialog windows are subclassed frames. When you call WinLoadDlg() or WinDlgBox(), you provide your dialog procedure address. After WinLoadDlg() (which is in turn called by WinDlgBox() if you call that) creates the frame and the controls, it then calls WinSubclassWindow() on the frame using your window procedure and saves the original frame procedure. So messages first come to your window procedure letting you deal with it. If you pass it to WinDefDlgProc() it will possibly handle it, in order to provide standard dialog functionality such as tabbing, or pass it on to the original WC_FRAME window procedure. So the effect is of a layered set of 'virtual message handlers' that cooperate in providing an extensible feature set, with each layer taking one of the above 4 approaches to each message received.

Superclassing

Superclassing is less often done than subclassing because its advantages, though sometimes significant, are often not needed enough to justify it. The best way to understand the differences between subclassing and superclassing is to realize that subclassing is for applying per-window overriding of messages. In order words, subclassing is done on a per-window basis, after a window has already been created. The creator of the window usually decides whether he/she wants to apply the subclass, not the window itself. Another disadvantage of subclassing is that, since the window must already exist in order to subclass it, the WM_CREATE processing happens before the subclass can be applied.

It would be nice to be able to extend, limit, or otherwise modify the functionality of an existing window class such that it applied to all instances of that window (without explicit action having to be taken by the client code.) Superclassing provides these benefits. To superclass a window you must follow these steps.

Query the class information of the class to super class
Store away the count of extra data words it has and the window procedure of the class
Register a new window class, providing your own window procedure when you register the class.
If your window class needs any extra window data beyond that of the original class, add your needs to the original class' when you register your new class. One reason you might want to create extra window words is to have a place to store per-window information without using the QWL_USER area that the users of the new window class might need.

The important things to note here is that you have created a new window class. So, when client code creates the window, it will provide your window class to WinCreateWindow(). This has important ramifications to your control of the situation. They are:

Since the client is creating your window class, you will get the WM_CREATE message. Make sure that you pass it on to the underlying window class first, to let it handle its initialization. Then take care of your own initialization needs.
You are in control of the situation. You don't need to count on client code to create a window of one class and then apply some subclass you provide to it. This means that the superclass will naturally apply to all instances of the window, not just to selected instances of it.
You get to add more per-window instance data words, which is often necessary. You cannot use any existing window words because they could all be used by the window class you superclassed (or by per-instance subclasses applied by client code.) By adding your storage needs to the underlying class' your data is at indexes beyond those accessed by other users of the window (because they don't know they even exist probably.)
You can tell at runtime whether a window is of your particular class because you can query its class name or class info. There is not an easy way to tell if a subclassed window has had a particular subclass applied to it. You cannot just compare its stored window procedure address with your class' window procedure because it could have been subclassed as well by client code.

Owner Draw

Some standard controls support an 'owner mode'. This is not a subclass or superclass because, in this case, the control is just letting its owner window handle a particular aspect of its visual appearance. Subclassing and superclassing are applied to the control window itself and prevent the parent/owner windows from having to be particularly aware of them once they are set up.

If you see a problem with this web site, contact edm2_eds@iqpac.com.