bug#11732: Follow-up to bug#11732

[Eli Zaretskii]

> Date: Sat, 30 Jun 2018 10:06:57 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: mhatta@gmail.com, 11732@debbugs.gnu.org
> 
>  > SWP_NOACTIVATE was just a copy-paste from similar calls elsewhere.
>  > The rationale for the code was to tell windows to put the frame from
>  > which the file-selection dialog popped behind the dialog.
> 
> IMO these two calls are not entirely kosher - after all the dialog box
> is in the topmost group and the selected frame not.  So some other
> application that interrupts the dialog might mess things up.  Anyway,
> I would try moving the SWP_NOACTIVATE from the dialog to the selected
> frame call like
> 
>         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, 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...

>  > If
>  > w32_dialog_in_progress is meant to do that, I don't understand how it
>  > does that; can you explain?
> 
> All w32_dialog_in_progress does is moving frames from and to the
> topmost group.  I don't like putting frames in the topmost group - but
> if one doesn't use child frames and wants a support frame on top of a
> normal frame, setting just the z-order is not enough: You run into an
> eternal loop where Emacs tries to put the support frame above the
> normal one and Windows immediately reverses that because I obviously
> want the normal frame to retain focus.

By "support frame" here you mean the dialog box?  If not, then why is
this function called every time we are about to show a dialog box?

>  > (Btw, as long as we are discussing this: the above-suspended value of
>  > the z-group frame parameter appears to be completely undocumented.)
> 
> Conceptually, users should never see it: It is set only during
> dialogs.  But if you think it should be documented I'll do that.

If it's an internal setting that should never be seen outside the C
sources, then it should be documented in the commentary preceding
x_set_z_group, and the comment should tell this value is internal, so
that whoever reads the code will understand what each setting wants to
achieve.

>  > +  if (msg == WM_NOTIFY)
>  > +    {
>  > +      SetWindowPos (hdlg, HWND_NOTOPMOST, 0, 0, 0, 0,
>  > +              SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE
>  > +              | SWP_NOOWNERZORDER);
> 
> The HWND_NOTOPMOST doesn't look good - dialog boxes should be topmost.
> Could you try with
> 
> static UINT_PTR CALLBACK
> font_dialog_callback (HWND hdlg, UINT msg, WPARAM wParam, LPARAM lParam)
> {
>    static HWND cf_hwnd;
> 
>    if (msg == WM_INITDIALOG)
>      cf_hwnd = ((CHOOSEFONT *)lParam)->hwndOwner;
> 
>    if (msg == WM_NOTIFY)
>      {
>        SetWindowPos (hdlg, HWND_TOPMOST, 0, 0, 0, 0,
>                   SWP_NOMOVE | SWP_NOSIZE | SWP_NOOWNERZORDER);
>        SetWindowPos (cf_hwnd, hdlg, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE
>                   | SWP_NOACTIVATE);
>      }
>    return 0;
> }

This looks good on XP, 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.

> It doesn't show any strange effects here, at least.

I think the problems I saw were on Windows 7.  Will check.

Thanks.