bug#11732: Follow-up to bug#11732

[martin rudalics]

> 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