[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#11732: Follow-up to bug#11732

From: martin rudalics
Subject: bug#11732: Follow-up to bug#11732
Date: Fri, 29 Jun 2018 10:43:12 +0200

>> Tested with "File -> Open File" dialog and "(w32-font-select)" dialog.
>> Both seem to work.
> By "work", do you mean that clicking on anywhere inside these dialogs
> leaves the dialogs visible?  On 2 different systems where I tried
> this, after applying the patch, clicking anywhere in the dialog box
> after it opens causes the dialog box to disappear: it is moved in z
> order behind the frame from which the dialog was started.
> It's possible that this is somehow related to the fact that I have my
> Windows systems configured to enable "active window tracking"
> (a.k.a. "focus follows mouse"), but even so, I'd like to be able to
> avoid that adverse side effect on systems that are so configured.

I now tried on my standard XP machine and do not see any adverse
effects with file, directory and font dialog boxes.  Maybe it's
related to the fact that I have "focus follows mouse" plus
"autoraise".  Could you try with such a setting?  I am very reluctant
to change mine becaue I have some additional mouse software working as

> +    SetWindowPos (dialog, HWND_TOPMOST, 0, 0, 0, 0,
> +                  | 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)?  The patch does not have any (adverse) effects here so if it
solves the problem for you, I see no problem applying it.

> then how do
> we solve a similar problem in x-select-font?  It doesn't have a
> callback function, and if I try adding one, the appearance of the
> dialog changes(??) and the OK and CANCEL buttons no longer work.

Can you send me the code you tried?

> Also, w32_dialog_in_progress seems to try to solve some similar
> problem, but is not really working?  I guess I simply don't understand
> why the dialog is lowered when I click on it.

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]