Changes to multiwindow mode and always-on-top (ping Takuma)

[Earle F. Philhower III]

Hello Takuma,

At 07:56 PM 3/20/2004 +0900, Takuma Murakami wrote:
>You give me a good insight to improve Z order handling.
>I believe we can approach to better solutions.  The attached
>is my latest code which should fix all problems on restacking
>and a-o-t windows without using fAlwaysOnTop flag.  Could you
>try and review this?

It works great from my testing today!  On Monday I'll bring it to
work for a harder test, I normally have 10 or so emacs and xterms
running with an occasional EDA tool.  (It seems that cygwin's
emacs-x11 has some problems, not due to these changes, so I can't
get too many started locally to test...)

> > of the regular stack.  It's a 1 line change in winmultiwindowwndproc.c.
>It must be the SetWindowPos() in the winTopLevelWindowProc's
>WM_SHOWWINDOW handler.  I removed SWP_NOACTIVATE flag since
>popups can't get into the front with the flag.

Yes, seems fine w/o that flag set.  The HWND_TOPMOST still gets set
fine, and menus stay in the top z-pane.  I just put it in there
because during some intermediate testings I left all created windows
as OVERLAPPEDWINDOW and not set back to POPUP (for the cascading).

>In recent changes I made winRestackWindowMultiWindow empty

I was wondering about the #if 0 on this section, but your new
reorder routine seems to keep things working 100%.

>and removed winReorderWindowsMultiWindow(), which were my
>fault and forced you to reinvent PreserveWin32Stack().  I think
>winReorderWindowsMultiWindow() is Kensuke's version of
>PreserveWin32Stack().  He does the work in X server's internal
>function (ConfigureWindow) while you do through WM thread
>(XRaiseWindow).

Yes, I'm more familiar with Xlib than internal DDX routines,
so chose the one I understood.  The restacking you've put
back in the ReorderMW works just as well, or probably better.

One thing I was worried about, and I see that you've taken care
of, is the fact that since we iterate over the Win32 window stack
and do a series of ConfigureWindow/etc., those ConfigureWindows()
might cause yet another Restack call, resulting in up to ((n*(n-1))/2)
calls.  The fRestacking flag you put back in looks like the easiest
way of handling this...

Thanks, I'll let you know if anything pops up in my testing!

-Earle F. Philhower, III
  earle@ziplabel.com
  cdrlabel - ZipLabel - FlpLabel
  http://www.cdrlabel.com