GNU bug report logs - #11732
26.1; Japanese IME input problem on Windows

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Masayuki Hatta <mhatta <at> gmail.com>
Cc: 11732 <at> debbugs.gnu.org
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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.