bug#11732: Follow-up to bug#11732

[martin rudalics]

> Will do, just not today.
>
>>   > +         SetWindowPos (dialog, HWND_TOPMOST, 0, 0, 0, 0,
>>   > +                       SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE
>>   > +                       | SWP_NOOWNERZORDER);
>>   > +         SetWindowPos (FRAME_W32_WINDOW (SELECTED_FRAME ()),
>>   > +                       dialog, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
>>
>> What was the more or less precise rationale for this unless it was
>> pure experimenting (in particular the SWP_NOACTIVATE in the first
>> call)?
>
> 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.

> 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.

> (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.

> Below.  It's possible I've put the code in the wrong WM_* message, but
> I'm really stabbing in the dark in these matters.
>
>> In w32_dialog_in_progress I tried to solve a relatively simple
>> problem: When a frame is in the TOPMOST group and I start a dialog,
>> that frame would obscure the dialog box.  So I temporarily remove the
>> frame from the TOPMOST group and move it back when the dialog ends.
>
> Can you show me some Lisp to try this situation?
>
> Here's the patch I used with the font-selection dialog:

> +  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;
}

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

martin