[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: |
Fri, 29 Jun 2018 12:07:16 +0300 |
> Date: Fri, 29 Jun 2018 10:43:12 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 11732@debbugs.gnu.org
>
> 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?
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. If
w32_dialog_in_progress is meant to do that, I don't understand how it
does that; can you explain?
(Btw, as long as we are discussing this: the above-suspended value of
the z-group frame parameter appears to be completely undocumented.)
> The patch does not have any (adverse) effects here so if it
> solves the problem for you, I see no problem applying it.
OK.
> > 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?
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:
--- src/w32font.c~ 2018-01-03 13:09:26.000000000 +0200
+++ src/w32font.c 2018-06-27 18:19:04.140101200 +0300
@@ -2505,6 +2505,24 @@ compute_metrics (HDC dc, struct w32font_
metrics->status = W32METRIC_FAIL;
}
+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_NOTOPMOST, 0, 0, 0, 0,
+ SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE
+ | SWP_NOOWNERZORDER);
+ SetWindowPos (cf_hwnd, hdlg, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
+ }
+ return 0;
+}
+
DEFUN ("x-select-font", Fx_select_font, Sx_select_font, 0, 2, 0,
doc: /* Read a font name using a W32 font selection dialog.
Return fontconfig style font string corresponding to the selection.
@@ -2527,7 +2545,8 @@ in the font selection dialog. */)
cf.lStructSize = sizeof (cf);
cf.hwndOwner = FRAME_W32_WINDOW (f);
- cf.Flags = CF_FORCEFONTEXIST | CF_SCREENFONTS | CF_NOVERTFONTS;
+ cf.Flags = CF_FORCEFONTEXIST | CF_SCREENFONTS | CF_NOVERTFONTS |
CF_ENABLEHOOK;
+ cf.lpfnHook = font_dialog_callback;
/* If exclude_proportional is non-nil, limit the selection to
monospaced fonts. */
- bug#11732: Follow-up to bug#11732, (continued)
- 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, 2018/06/29