[shell-coding] owner/owned zorder

there are some issues with the zorder of owner/owned windows

litestep's main window isn't owned or parented to anything, but modules like
desktop2, label and layercuts are owned by it. the problem has to do with
owner/owned windows wanting to move in the zorder as a group, ie. change
one's zorder and they're all shifted.

as desktop2 wants to be below everything else, it has to shift downward to
counter the z-motion of other windows that would otherwise end up below it.
because it is owned by litestep, the litestep window also shifts and so does
its owned windows like label and layercuts. if label or layercuts are
topmost, this causes them to drop back to regular toplevel status.

this seems most evident on resolution changes, i suppose every which window
might be attempting to reset it's zorder at that point and the desktop loses
out and changes zorder at least temporarily ?

this is all just how it seems to be working to me, but based on this the
following seems like good general rules (which do seem to solve the issue of
labels/layercuts being dragged out of topmostness..) :


 - owned windows should use SWP_NOOWNERZORDER (in SetWindowPos()) and
probably something like (((WINDOWPOS *)lParam)->flags |= SWP_NOOWNERZORDER)
in WM_WINDOWPOSCHANGING

 - the desktop should not be owned (it could follow the rule above, but as
it fights for bottommostness, it seems better not to have to worry about it)

 - the litestep window should possibly use something like (((WINDOWPOS
*)lParam)->flags |= SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER |
SWP_NOOWNERZORDER) for WM_WINDOWPOSCHANGING. this to let it protect the
zorder itself in case some modules don't follow the rules above


anyone have any insight on this? something i've gotten wrong or missed, or
some improvements on the "rules"?


__________________________________________________
Subscription options and archive:
http://www.freelists.org/list/shell-coding

Other related posts: