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

Previous Next

Package: emacs;

Reported by: xavier.dahan <at> gmail.com

Date: Mon, 18 Jun 2012 06:41:01 UTC

Severity: normal

Tags: patch

Found in version 24.1

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Masayuki Hatta <mhatta <at> gmail.com>, martin rudalics <rudalics <at> gmx.at>
Cc: 11732 <at> debbugs.gnu.org
Subject: bug#11732: Follow-up to bug#11732
Date: Wed, 27 Jun 2018 18:54:04 +0300
> From: Masayuki Hatta <mhatta <at> gmail.com>
> Date: Tue, 26 Jun 2018 18:10:26 +0900
> 
> Recently I built Emacs 26.1 on Windows 10 (w/ MSYS2 64bit) with the
> patch as mentioned earlier.  It works as expected and seems to bring
> no lousy side effects anymore.
> 
> This problem has been making Emacs on Windows almost unusable for
> Japanese users (so most of them use their patched binary).  Thus I
> appreciate if you apply the patch again.
> 
> 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.

Martin, could you perhaps look into this?  I tried various
"solutions", and the best I could come up with is the patch below.  If
it looks right to you (I'm really out of my depth here), 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.

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.

Here's the patch for file_dialog_callback I came up with:

--- src/w32fns.c~	2018-06-11 06:32:21.000000000 +0300
+++ src/w32fns.c	2018-06-27 18:22:27.104228200 +0300
@@ -7520,6 +7520,12 @@ file_dialog_callback (HWND hwnd, UINT ms
 	  HWND list = GetDlgItem (dialog, FILE_NAME_LIST);
 	  int hdr_code;
 
+	  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);
+
 	  /* At least on Windows 7, the above attempt to get the window handle
 	     to the File Name Text Field fails.	 The following code does the
 	     job though.  Note that this code is based on my examination of the




This bug report was last modified 7 years and 12 days ago.

Previous Next


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