bug#11732: Follow-up to bug#11732

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 30 Jun 2018 14:51:04 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: mhatta@gmail.com, 11732@debbugs.gnu.org
> 
>  >> 	  SetWindowPos (dialog, HWND_TOPMOST, 0, 0, 0, 0,
>  >> 			SWP_NOMOVE | SWP_NOSIZE | SWP_NOOWNERZORDER);
>  >> 	  SetWindowPos (FRAME_W32_WINDOW (SELECTED_FRAME ()),
>  >> 			dialog, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE
>  >> 			| SWP_NOACTIVATE);
>  >>
>  >> Note that I can't test it because nothing is broken here in the first
>  >> place.
>  >
>  > I think I tried with HWND_TOPMOST,
> 
> You had HWND_TOPMOST here in the patch you attached to the first
> message I read.

Right, sorry.  The issue still stands, though.

>  > but what it does (and I see it now
>  > with your suggestion) is it doesn't allow raising any other
>  > (non-Emacs) window above the file-selection dialog (in the z-order).
>  > The original code didn't behave that way, so I looked for a better
>  > option, and HWND_NOTOPMOST seemed to do the job...
> 
> I probably don't understand the original problem sketched as
> 
> 	 But doing so causes trouble with displaying
> 	 dialog boxes, such as the file selection dialog or font
> 	 selection dialog.
> 
> A dialog box uses a modal window on top of the owning window.

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.

>  > If not, then why is
>  > this function called every time we are about to show a dialog box?
> 
> Because a dialog box should appear on top of any support frame.  And
> it doesn't necessarily do that when both are in the topmost group.
> That's why I temporarily remove the support frame from that group.

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?

>  > I will try on Windows 7 later.  Curiously,
>  > HWND_TOPMOST here doesn't prevent raising other windows above the
>  > dialog box, as it does with file selector.
> 
> The windows of other applications (including other Emacs instances) or
> that of the Emacs instance involved in the dialog?

The former.

> Note that Emacs waits for the dialog to finish and doesn't redisplay
> in this time.  Hence if during a dialog I temporarily show another
> window on top of the dialog and remove that other window, the text in
> the Emacs frame is usually garbled until the dialog finishes.

Yes, I know.  That wasn't what I was worried about.

Thanks.