Re: considering modifier keys after gaining focus

[Oliver Schmidt <oschmidt-mailinglists@gmx.de>]

Hi Jon,

On 09.01.2012 15:06, Jon TURNEY wrote:
> I have a few questions and comments below:
> 
>> Example: in window A Ctrl + some key opens a window B, then in window B
>> Ctrl + some other key triggers the next action. However after the opening
>> of window B the Ctrl key has to be released and pressed again. If the user
>> keeps the Ctrl key holding when the window B is opened, the next key press
>> X will be interpreted as X and not as Ctrl+X.
> 
> Can you give an example of an application where this causes a problem, so I
> can test your patch?

because current cygwin x-server is not able to raise windows, you could
only test the case, that a new window is created. Any X11 program that
can create windows and has keyboard shortcuts will do it, e.g. take
NEdit, press Ctrl+N for a new window, hold the Ctrl key and press S
(i.e. Ctrl+S) for saving.

> The code would seem to end up simpler (which is an important consideration) if
> we were to modify winKeybdReleaseKeys() not to release modifier keys.  Some
> archaeology is probably required to determine if releasing the modifier keys
> in winKeybdReleaseKeys() is necessary to avoid some other undesirable behaviour?

I don't know anything about the cygwin X server history, I can only
guess why the current code is as it is: Perhaps the modifier keys are
released afer loosing a window's focus because if another Non-cygwin
window gains the focus, no more modifier change events will arrive to
the cygwin x server.

> This also begs the question why is it only necessary to press some some subset
> of the down keys on WM_SETFOCUS?  Does the X server behave correctly if a
> non-modifier key is held down while focus moves from one X server window to
> another, or from one X server window to a  native window an back?

My code simply updates the xserver's internal state about the modifier
keys after gaining the window focus. Other keys behave correctly,
because the xserver doesn't have an internal state for them.

> Why is is correct to use GetAsyncKeyState() here and not GetKeyState()?  If we
> use GetAsyncKeyState() there may be a message pending (See the remarks on
> GetKeyState() in MSDN) to change to the key state, so we might conceivably
> double the key press?

I will try using GetKeyState tomorrow. I just wanted to be sure to get
the current key state when the window gets the focus.

> This maps VK_CONTROL to KEY_LCtrl.  Why not use VK_LCONTROL and VK_RCONTROL,
> so the generated key-press is for the correct key?
> Ditto for VK_LSHIFT and VK_RSHIFT

Perhaps this might improve the patch, however the internal modifier
state of the xserver has only ShiftMask, LockMask, ControlMask,
Mod1Mask, Mod2Mask, Mod3Mask, Mod4Mask, and Mod5Mask. So the internal
state does not distinguish betweem left or right shift key.

Best regards,
Oliver

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/