GetKeyState Bug?

[Handoko]

Tested on Lazarus 2.0.10 GTK2 Ubuntu Mate 21.10, I found GetKeyState not working correctly:

• Pressing the [right_shift], triggers both signals
• Pressing the [left_shift] and moving the mouse pointer to the form will trigger the right_shift signal

Can you please test it on your system, before I buy myself a new keyboard.

Code: Pascal  [Select][+][-]

1. unit Unit1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, Forms, Graphics, ExtCtrls, LCLIntf, LCLType;
9.  
10. type
11.  
12.   { TForm1 }
13.  
14.   TForm1 = class(TForm)
15.     Shape1: TShape;
16.     Shape2: TShape;
17.     Timer1: TTimer;
18.     procedure Timer1Timer(Sender: TObject);
19.   end;
20.  
21. var
22.   Form1: TForm1;
23.  
24. implementation
25.  
26. {$R *.lfm}
27.  
28. { TForm1 }
29.  
30. procedure TForm1.Timer1Timer(Sender: TObject);
31. begin
32.  
33.   // Left Shift
34.   if GetKeyState(VK_LSHIFT) < 0 then
35.     Shape1.Brush.Color := clRed
36.   else
37.     Shape1.Brush.Color := clWhite;
38.  
39.   // Right Shift
40.   if GetKeyState(VK_RSHIFT) < 0 then
41.     Shape2.Brush.Color := clRed
42.   else
43.     Shape2.Brush.Color := clWhite;
44.  
45. end;
46.  
47. end.

[440bx]

Just in case this information might be helpful...

tested on Win7 SP1, Lazarus 1.8.4, FPC v3.0.4 -> no problems

tested on Win10 (21H1), Lazarus 2.2 RC1, FPC (whatever the version Lazarus uses is) -> no problems.

[howardpc]

I can confirm the bug on Laz 2.2.0RC2 Linux Mint GTK2.
Left shift works as expected, but moving the mouse pointer over the form then triggers the right shift signal.

Right shift triggers both signals, which can be cleared by moving the mouse pointer into the form area.

[Lulu]

All fine here, on Win10 (20H2) + Lazarus 2.010

[lagprogramming]

Indeed. Targeting linux-x86_64-gtk2 I find the same signal problems:

    Pressing the [right_shift], triggers both signals
    Pressing the [left_shift] and moving the mouse pointer to the form will trigger the right_shift signal

[winni]

Hi!

Add this to your timer procedure and sit back in amazment:

Code: Pascal  [Select][+][-]

1. label1.Caption := IntToStr (GetKeyState(VK_LSHIFT))+' / '+
2.                     IntToStr (GetKeyState(VK_RSHIFT));

VK_LShift returns :  -127 / 0
VK_RShift returns : -127 / -128, then -128/-128, then again -127/-128 .....

So you can decide:
if (VK_Rshift is 0) and (VK_Lshift < 0) then VKLshift ist pressed
if VK_Rshift is -128 then VK_Rshift is pressed

Miracles, miracles....

Lin64, gtk2

Winni
 

[MarkMLl]

• Pressing the [right_shift], triggers both signals
• Pressing the [left_shift] and moving the mouse pointer to the form will trigger the right_shift signal

Can you please test it on your system, before I buy myself a new keyboard.

Confirmed, also after left+over+release the right box remains red until the mouse if moved off. Lazarus 2.0.12 FPC 3.2.0 Debian "Buster" x86_64 using KDE desktop.

/However/, I'd caution that the right shift (and for that matter control etc.) has always been a bit weird (I've looked at this carefully on multiple occasions so that I can build a "mavenwerk" backdoor into a UI), and it's likely that the current situation is a feature carefully-crafted for Delphi compatibility.

MarkMLl

[winni]

Hi!

There will be a day where the only bug free parts of fpc/Lazarus are those which are not Delphi compatible ....

Winni

[MarkMLl]

There will be a day where the only bug free parts of fpc/Lazarus are those which are not Delphi compatible

I very carefully didn't (quite) say that, lest it sounded like criticism of the core team.

In actual fact I've been looking back through various code, and found comments (from myself) wingeing about how Delphi+Windows was actually better-implemented in that specific area. Hence this is very likely to be a widget set (or at least widget-set specific) area.

My earlier test where I could duplicate the problem used gtk2. Switching to gtk3... "Error while linking". SEP (sorry). Switching to qt5... oh crap.

This is a mess. If the window is foreground but the mouse is not over it releasing (not pressing) <L-shift> sets the LH window red, and even after it's released it stays red until the mouse is moved over the window. Pressing <R-shift> does exactly the same. If the mouse is over the window pressing either shift sets the LH window red, with some toggling behaviour that I can't quite fathom.

MarkMLl

[winni]

Hi!

Aside from this special problem:

The idea of

" This is not a bug because this bug is Delphi compatible"
- that can drive people to madness.
Including me.

Winni

[MarkMLl]

The idea of

" This is not a bug because this bug is Delphi compatible"
- that can drive people to madness.
Including me.

For once we're in agreement, but I'd also extend that to "this isn't in the spirit of Pascal so isn't going into this implementation".

MarkMLl

[loaded]

The code is working properly.
My work computer; Lazarus 2.0.12 32 Bit, Win 10 Enterprise 64 Bit

[Martin_fr]

Apparently it works differently on Windows and Linux. I don't think that such a diff is a "Delphi compatibility feature"....

[PascalDragon]

Hence this is very likely to be a widget set (or at least widget-set specific) area.

Yes, cause it's implemented in LCLIntf which is mainly involved for providing WinAPI compatibility. GetKeyState is a WinAPI function and on other widget sets this needs to be emulated. So either something is broken there or the underlying API can not provide the data correctly.

[MarkMLl]

Yes, cause it's implemented in LCLIntf which is mainly involved for providing WinAPI compatibility. GetKeyState is a WinAPI function and on other widget sets this needs to be emulated. So either something is broken there or the underlying API can not provide the data correctly.

I've always found the RH shift/ctrl keys to be a bit dodgy and widgetset-specific. I'm not as able to work back through older versions as I used to be, so can't be of very much practical help.

Has anybody checked GTK3 yet?

MarkMLl