bug#11732: Follow-up to bug#11732

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 01 Jul 2018 11:00:55 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: mhatta@gmail.com, 11732@debbugs.gnu.org
> 
>  > I didn't mean the owing window, I meant the other windows on the
>  > desktop, belonging to applications other than Emacs.  Using
>  > HWND_TOPMOST makes me unable to raise any window of another
>  > application above the dialog box in the z-order.  The existing code
>  > does allow that.
> 
> Because it leaves the entire z-order handling to Windows.  The idea of
> using a dialog box is that you tell Windows to glue together the frame
> with the dialog box and let no other window enter the z-order in
> between these two.  How Windows implements that has likely never been
> analyzed so we won't know.  But I suppose that Windows simply
> intercepts all (implicit) z-reorder requests to let no other window
> in.

Got it, thanks.

> Now if Masayuki's proposal breaks this relationship please tell me
> exactly how.  IIUC you mean to say that with focus follows mouse sans
> autoraise the two Emacs windows (always) appear on top of other
> applications.  But sans autoraise means that the z-order should not
> change when you move the mouse so you apparently clicked into another
> application's window or tried to Alt-tab to it.  Please clarify this
> giving us the precise steps you used.

The dialog appears on top of the frame from which it was invoked as
usual, and as expected (since Windows raises the frame when you click
on its menu, the frame is indeed usually on top of the other apps,
modulo apps like Task Manager that force themselves on top of
everything).  Then any click _anywhere_ inside the dialog causes the
dialog to disappear, because the owning frame is raised to cover it.
A second click at the same coordinates causes the dialog to be shown
blinking, as when you click on some part outside the dialog.  My
workaround for that is to drag the dialog outside of its owning frame,
and then use it as usual.

Did I explain the situation clearly?

Btw, I have now established that focus follows mouse causes this: if I
disable it, the problem disappears.  And autoraise doesn't affect the
issue in any way.  I tried both X-Mouse Controls and Winaero Tweaker,
on 2 different Windows 7 systems, with the same result: enabling
focus-follows-mouse causes the issue, disabling it makes the issue go
away.  (Of course, both Windows 7 systems were configured by yours
truly, so maybe there's some other factor acting as a catalyst.  But
all else being equal, just turning on and off focus-follows-mouse
causes the problem to appear or disappear on those 2 systems.)

>  > OK, so the call to w32_dialog_in_progress has nothing to do with the
>  > z-order of the dialog wrt its owning frame, right?
> 
> Right.  I meanwhile tried to document this better.  Please have a
> look.

LGTM, thanks.