bug#11732: Follow-up to bug#11732

[martin rudalics <rudalics@gmx.at>]

 > 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