[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
well.
> + 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)? 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.
martin
- bug#11732: Follow-up to bug#11732, (continued)
- bug#11732: Follow-up to bug#11732, Eli Zaretskii, 2018/06/28
- bug#11732: Follow-up to bug#11732, Noam Postavsky, 2018/06/28
- bug#11732: Follow-up to bug#11732, Eli Zaretskii, 2018/06/28
- bug#11732: Follow-up to bug#11732, Masayuki Hatta, 2018/06/29
- bug#11732: Follow-up to bug#11732, martin rudalics, 2018/06/29
- bug#11732: Follow-up to bug#11732, Eli Zaretskii, 2018/06/29
- bug#11732: Follow-up to bug#11732, Masayuki Hatta, 2018/06/29
- bug#11732: Follow-up to bug#11732, Eli Zaretskii, 2018/06/30
- bug#11732: Follow-up to bug#11732, Masayuki Hatta, 2018/06/30
- bug#11732: Follow-up to bug#11732, Eli Zaretskii, 2018/06/29
bug#11732: Follow-up to bug#11732,
martin rudalics <=
- bug#11732: Follow-up to bug#11732, Eli Zaretskii, 2018/06/29
- bug#11732: Follow-up to bug#11732, martin rudalics, 2018/06/30
- bug#11732: Follow-up to bug#11732, Eli Zaretskii, 2018/06/30
- bug#11732: Follow-up to bug#11732, martin rudalics, 2018/06/30
- bug#11732: Follow-up to bug#11732, Eli Zaretskii, 2018/06/30