[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11732: Follow-up to bug#11732
From: |
Eli Zaretskii |
Subject: |
bug#11732: Follow-up to bug#11732 |
Date: |
Sat, 30 Jun 2018 16:21:41 +0300 |
> 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.
bug#11732: Follow-up to bug#11732, martin rudalics, 2018/06/29