Content-Length: 7978 Content-Type: text/html Window Parentage

Window Parentage

Every window in PM except for the magical desktop (HWND_DESKTOP) and object (WM_OBJECT) windows have parent windows. This is a required relationship that always exists, though the parent of a window may be changed as desired. Parenthood implies these facts:

All windows are placed relative to their parent window. When you query or set a window's position, that position is relative to the lower left corner of its parent window.
Since windows cannot exist without a parent, they are destroyed when their parent is destroyed. This is both a convenience and a necessity.
When a window gets a WM_DESTROY, its child windows still exist so that they can be queried, their size/position saved, etc....
When a window gets its WM_CREATE message it cannot have any child windows because no one could have created any yet (other than PM itself who won't). The window handle is not returned from WinCreateWindow() until WM_CREATE processing is completed, so no one has had access to the window in order to create a child window for it or assign one to it.
Child windows will never show outside of their parent windows because they clipped to it. This is a natural effect of PM and does not require any special effort on your part.
WinQueryWindow(hwndChild, QW_PARENT) cannot fail if hwndChild is a valid window because it must have a parent to exist. There might be some pathological multi-threaded situation where the query is made while the switch is occurring.

Parenthood of a window can be changed using the WinSetParent() API. This API is used often by PM to control, for instance, menus which often must appear and disappear on demand. Instead of rebuilding them every time, their parent is set to HWND_OBJECT, which hides them without affecting their size/position information. You can use this scheme yourself to say display one of a set of windows in a particular area of your client screen according to some circumstance. Be aware that, when you do this, those windows will not be destroyed automatically when your client is destroyed now because automatic destruction only occurs for child windows. So you must generally track them by window handle so you can destroy them when you get a WM_DESTROY message. You cannot use ids to find them because any process can have windows under HWND_OBJECT, some of which could have your same id. Another exception to this rule is that frame windows will destroy all of their child windows (naturally like everyone else does) plus all of their owned windows. This makes sure it gets all of those windows cleaned up successfully.

Window Ownership

Whereas window parentage is a somewhat 'physical' relationship, ownership is more of a 'legal' relationship. In PM, when a user interacts with a control window, that window will send a WM_CONTROL message to its owner window. In an object oriented system, this would have probably worked the other way where control windows would handle their own events in an extendable way via polymorphism; but, in a non-OOPs system, the most practical way to provide extensibility of the standard controls is to let the client code respond on their behalf as suits the application's particular circumstances. Given that, there arose the need to know 'who' was interested in these events. Therefore an artificial relationship of ownership was invented, so that a 'legal contract of notification' could be arranged between two windows. Ownership is not affected by the parenthood heirarchy at all, so a window's owner could possibly be almost any other window.

Since this relationship is more artificial, it can be ignored totally (i.e. a window is not required to have an owner) and it can be used by custom window classes to represent some other type of legal contract. The (almost) only reason it is magical at all is because WinQueryWindow() allows a window's owner to be queried. But you could easily arrange to provide other relationships between your own windows if you wish to do so. It would be more work than ownership because you would have to provide your own internal mapping tables or store a reference to the other window inside each window. But it would be just as 'legitimate' a relationship as ownership.

Ownership can be changed or set via the WinSetOwner(). It can be set to 0, to make the window no longer have an owner. This might be a convenient way to make child controls 'shut up' for extended periods of time when the owner is not prepared to deal with them.

Note that the ownership relationship is used (just for confusion's sake) for a couple things other than the event notification. Presentation parameters can be inherited via the ownership chain and frame windows have an option to be moved relative to their owner. This allows them to float outside their parent but maintain the same position relative to it. Also, frame windows minimize their owned windows when they are minimized and destroy their owned windows when they are destroyed, which is unlike any other window class.

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