bug#11732: Follow-up to bug#11732

[martin rudalics]

>>          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.  I only moved the SWP_NOACTIVATE from the dialog
window to that of the selected frame.

> 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.
Anything else will almost certainly cause problems with any windowing
system we use.

> By "support frame" here you mean the dialog box?

No.  I mean a frame that in many regards acts like a child frame but
uses a top-level window instead of a child window.

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

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

OK.  I'll do that.

> This looks good on XP,

Your initial patch for the font dialog showed many bad symptoms
(buttons not responding, couldn't drag the dialog box, combo box for
script dropping down beneath the dialog box) 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.

The windows of other applications (including other Emacs instances) or
that of the Emacs instance involved in the dialog?

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.

martin