unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 11732@debbugs.gnu.org, mhatta@gmail.com
Subject: bug#11732: Follow-up to bug#11732
Date: Tue, 03 Jul 2018 10:29:59 +0200	[thread overview]
Message-ID: <5B3B3407.3020300@gmx.at> (raw)
In-Reply-To: <83sh53kp1j.fsf@gnu.org>

 > The dialog appears on top of the frame from which it was invoked as
 > usual, and as expected (since Windows raises the frame when you click
 > on its menu, the frame is indeed usually on top of the other apps,
 > modulo apps like Task Manager that force themselves on top of
 > everything).  Then any click _anywhere_ inside the dialog causes the
 > dialog to disappear, because the owning frame is raised to cover it.
 > A second click at the same coordinates causes the dialog to be shown
 > blinking, as when you click on some part outside the dialog.

Confirmed (finally, it took me some time to get my Windows 7 version
up and running again) with the autoraising option set.  The blinking
might be caused by some z-order fight maybe stopped by some timeout.

 > My
 > workaround for that is to drag the dialog outside of its owning frame,
 > and then use it as usual.

That's no workaround on my Thinkpad.  The two windows will always
overlap each other and I cannot shrink any of them because Windows
does not allow it.

 > Did I explain the situation clearly?

You did.

 > Btw, I have now established that focus follows mouse causes this: if I
 > disable it, the problem disappears.  And autoraise doesn't affect the
 > issue in any way.  I tried both X-Mouse Controls and Winaero Tweaker,
 > on 2 different Windows 7 systems, with the same result: enabling
 > focus-follows-mouse causes the issue, disabling it makes the issue go
 > away.  (Of course, both Windows 7 systems were configured by yours
 > truly, so maybe there's some other factor acting as a catalyst.  But
 > all else being equal, just turning on and off focus-follows-mouse
 > causes the problem to appear or disappear on those 2 systems.)

No further explanations needed, the problem is clearly visible here
now.  Do you have any explanation why calling DefWindowProc when
handling WM_IME_STARTCOMPOSITION causes this aberrant behavior and not
any of the other cases where we call DefWindowProc?

martin





  reply	other threads:[~2018-07-03  8:29 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-18  5:20 bug#11732: 24.1; Microsoft IME Japanese input problem xavier.dahan
2015-02-17 10:26 ` Fujii Hironori
2015-02-18 15:17   ` Eli Zaretskii
2015-02-19  2:03     ` Fujii Hironori
2015-02-19  6:44       ` Eli Zaretskii
     [not found]         ` <CALus1PmqiC8TnQTfcpVFD5ObjqbK_4hkOczRKmG1=+mkWXUHWQ@mail.gmail.com>
2015-02-19 11:44           ` Eli Zaretskii
2015-03-06 20:29             ` Eli Zaretskii
2015-03-06 22:37               ` Fujii Hironori
2015-03-07 10:53                 ` Eli Zaretskii
2015-03-09  2:13               ` Fujii Hironori
2015-03-09 16:30                 ` Eli Zaretskii
2018-06-26  9:10 ` bug#11732: Follow-up to bug#11732 Masayuki Hatta
2018-06-27 15:54   ` Eli Zaretskii
2018-06-28  8:04     ` martin rudalics
2018-06-28 10:13       ` Masayuki Hatta
2018-06-28 12:25         ` martin rudalics
2018-06-28 13:09           ` Eli Zaretskii
2018-06-28 10:11     ` Masayuki Hatta
2018-06-28 13:28       ` Eli Zaretskii
2018-06-28 19:17         ` Noam Postavsky
2018-06-28 19:24           ` Eli Zaretskii
2018-06-29  7:39             ` Masayuki Hatta
2018-06-29  8:43               ` martin rudalics
2018-06-29  8:59                 ` Eli Zaretskii
2018-06-30  3:14                 ` Masayuki Hatta
2018-06-30  7:46                   ` Eli Zaretskii
2018-06-30  8:30                     ` Masayuki Hatta
2018-06-29  8:56               ` Eli Zaretskii
2018-06-29  8:43     ` martin rudalics
2018-06-29  9:07       ` Eli Zaretskii
2018-06-30  8:06         ` martin rudalics
2018-06-30 11:32           ` Eli Zaretskii
2018-06-30 12:51             ` martin rudalics
2018-06-30 13:21               ` Eli Zaretskii
2018-07-01  9:00                 ` martin rudalics
2018-07-01 14:29                   ` Eli Zaretskii
2018-07-03  8:29                     ` martin rudalics [this message]
2018-07-03 18:50                       ` Eli Zaretskii
2018-07-07  7:45                         ` Tak Kunihiro
2018-07-07 10:00                           ` Eli Zaretskii
2018-07-07 10:21                             ` martin rudalics
2018-07-07 11:32                               ` Eli Zaretskii
2018-07-01 14:34             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5B3B3407.3020300@gmx.at \
    --to=rudalics@gmx.at \
    --cc=11732@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=mhatta@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).