The TShiftState enum in LCL includes ssNum, ssCaps and ssScroll elements, which should indicate the state of NumLock, CapsLock and ScrollLock correspondingly.

However under Win32 KeyDown/Up and MoudeUp/Down/Move events do not recieve these elements, while MouseWheel events do. This required a workaround at least for TAChart:
https://github.com/graemeg/lazarus/commit/1b2369b24de952d5ef250f3a4be7607d66d55da7#L0R710

Delphi does not have these elements, and, since they are usually not working anyway,
I suggest to remove them.

See http://bugs.freepascal.org/view.php?id=20065.
Also there are duplicate functions in Forms and Controls units (apart form the function which handles the WMWheel in win32), which should be de-duplicated.
IMO the function should be/stay implemente in Controls and enhanced (i.e. move the win32 function to Controls).

They are declared in FPC, so I think this is not an easy call.

-Fl?vio

2011/10/4 Fl?vio Etrusco :

Do I understand correctly that after this patch ssNum/ssCaps/ssScroll will not be included in the Shift argument of DoMouseWheel? If so, +1 from me.

I see. Let them be then, they are harmless if never set ;-)

Yes.

>> Delphi does not have these elements, and, since they are usually not working anyway,

This is easily fixable ;-) But until now I didn't realize this breaks code written for Delphi that checked for empty set or superset. I take back my argument for handling them in other messages then. The LCL implements GetKeyState anyway (although I'd prefer it was "pascalized" to avoid bitmasks...)

-Fl?vio

2011/10/4 Fl?vio Etrusco :

Of course. There should be a way to check key locks state, TShiftState is just not a good place for this.

I didn't realize "lock" meant this either :-$
BTW, does Delphi support ssAltGr and ssWin?

2011/10/4 Fl?vio Etrusco :

BTW, does Delphi support ssAltGr and ssWin?

No: http://docwiki.embarcadero.com/VCL/en/Classes.TShiftState

However, in this case I think Delphi is wrong, since those are real modifiers.

Hmm, since Borland itself introduced new modifiers (touch, pen, etc), shouldn't we consider code that relies on the original enum constants to be broken? AFAICS the key state will report whether the "lock key" is pressed down, not it's toggled state.

-Fl?vio

2011/10/4 Fl?vio Etrusco :

Hmm, since Borland itself introduced new modifiers (touch, pen, etc), shouldn't we consider code that relies on the original enum constants to be broken?

First, the code which relies on original enum elements will not be broken by addition of the new ones.
The code which relied on the fact that all enum elements represent *currently pressed* buttons/keys does get broken by ssNum and company. Embarcadero's additions seems ok to me, since they follow the standard pattern.

AFAICS the key state will report whether the "lock key" is pressed down, not it's toggled state.

No, at least in my tests on Win32 they did indicate toggled state. Otherwise | would not have a problem in the first place.

+1

The keyboard lock states (ssNumLock etc.) modify *keyboard* input (WM_KEYUP/DOWN), but are not normally usable with *mouse* input (WM_LBUTTONUP/DOWN). That's why mouse input also does not normally distinguish between e.g. left and right CTRL or SHIFT key, because left handed people will use the modifier keys at the right side, when operating the mouse with the left hand.

I see no reason for adding them to TShiftState, they better belong to GetAsyncKeyState etc.

DoDi

AFAIR GetAsyncKeyState encodes both the key state (up/down) and the lock state (locked/unlocked) in different bits of the byte array. But this may be different on other platforms, possibly unavailable information (private to the keyboard driver...). On mobile devices without a (full) keyboard the shift and lock states may be emulated, not corresponding to physically absent keys.

Therefore the TShiftState, as used with mouse messages, should include only commonly available keys and buttons, as far as *usable* to modify *mouse* operations. A software, checking for e.g. a combination of CTRL-left and SHIFT-right while the mouse wheel is turned, would not be very "handy" to use ;-)

DoDi

My bad, indeed the code checks for toggled state.

-  if (GetKeyState(VK_MENU) and $8000)  0 then
-    Result := Result + [ssAlt];
-  if (GetKeyState(VK_NUMLOCK) and 1)  0 then
-    Result := Result + [ssNum];
-  //TODO: ssSuper
-  if (GetKeyState(VK_SCROLL) and 1)  0 then
-    Result := Result + [ssScroll];

-Fl?vio