"Windows maintains the Z order in a single list."
Yet it's pretty obvious that Z order is best maintained as a tree of Z
lists. At least the programmer could reasonably conceptualize the Z order
as a hierarchical tree. The documentation for GetNextWindow() and
GetWindow() clearly suggest that operations such as GW_HWNDNEXT and
GW_HWNDPREV are bounded by a sub-Z list of siblings and return NULL when
you've gone off the end of the immediate level.
After finally feeling motivated to look deeper into this matter I
discovered, yes indeedy, that Z order is maintained as a tree:
"Win32 Window Hierarchy and Styles"
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/msdn_styles32.asp
Cool, now I can sleep better. But this brings me to the main concern of
this post - SetWindowPos(). Is it just me or does the documentation of
SetWindowPos() seem...well...sloppy? Perhaps the writers didn't want to
confuse the matter with too much detail, but the SetWindowPos() doc
appears to return us back to a flat Z list (or perhaps simply a case of
neglected children). Consider this example:
child1 and child2 are windows with different parents. Suppose we do
SetWindowPos(child1, child2, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
I'd try it myself but I'm afraid it might destroy the fabric of spacetime
if it were attempted. The docs do not indicate that this would be invalid
yet I see no meaningful way for such an operation to be performed without
seriously perverting the Z order concept.
What about this:
SetWindowPos(child, HWND_TOP, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
The docs say that HWND_TOP "Places the window at the top of the Z order."
Wouldn't this function actually move the child to the front of the Z list
OF ITS SIBLINGS and not, as the doc suggests, to the front of the total Z
order?
The SWP_NOOWNERZORDER flag also seems peculiar. Assume I have 2 top-level
windows Owner and Owned. The rules say that Owned must always be ahead of
Owner in the Z order (but not necessarily adjacent - just somewhere
ahead). The only time that Owner would absolutely positively have to be
moved in the Z order is when I attempt to move Owned deeper into the Z
order than Owner:
SetWindowPos(Owned, HWND_BOTTOM, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
In which case the SWP_NOOWNERZORDER flag would be improper and either be
ignored or return an error.
Consider the other case of moving Owned to a new Z location but still
ahead of Owner. I can't imagine why Windows would take it upon itself to
move Owner as well to some new Z location - somewhere still behind Owned
(taking into account there could be several other windows owned by Owner
scattered throughout the Z list). But apparently I'm supposed to use
SWP_NOOWNERZORDER to tell Windows *not* to perform this mysterious and
undefined operation. That seems the safest bet for predictable results.
I've googled for more info but I keep finding the same ol' docs duplicated
all over creation. Does anybody have a pointer to better info on this
stuff? Or a simple insightful commentary would be welcomed.
sda_mail Scott | Yields over 30 blasts or
@comcast.net Amspoker | 80 gentle honks per charge!
^ my email |