[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: |
Tue, 03 Jul 2018 10:29:59 +0200 |
> 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
- bug#11732: Follow-up to bug#11732, martin rudalics, 2018/07/01
- bug#11732: Follow-up to bug#11732, Eli Zaretskii, 2018/07/01
- bug#11732: Follow-up to bug#11732,
martin rudalics <=
- bug#11732: Follow-up to bug#11732, Eli Zaretskii, 2018/07/03
- bug#11732: Follow-up to bug#11732, Tak Kunihiro, 2018/07/07
- bug#11732: Follow-up to bug#11732, Eli Zaretskii, 2018/07/07
- bug#11732: Follow-up to bug#11732, martin rudalics, 2018/07/07
- bug#11732: Follow-up to bug#11732, Eli Zaretskii, 2018/07/07