Recent

Author Topic: Mouse and key input bug  (Read 4270 times)

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: Mouse and key input bug
« Reply #15 on: June 22, 2019, 08:06:16 pm »
I test this code, but not press any key

I added a Button and an Edit to your project, and used the following OnClick event:
Code: Pascal  [Select][+][-]
  1. procedure TForm1.Button2Click(Sender: TObject);
  2. begin
  3.   MouseInput.Move([], MyX, MyY, 1000);
  4.   MouseInput.DblClick(mbLeft, []);
  5.   Application.ProcessMessages;
  6.   SendStringInput(Edit1.Text);
  7. end;

Of course, as you know, you need to click on the memo before testing.

It works here: WinXP 32bit. I just checked, nothing indicates a change on Win10. This leaves one possibility, assuming I did not make a mistake in the code, if you are using 64bit system, there might be a problem with the record size/alignment of TInput and/or TKeybdinput in unit JwaWinUser.

1st Edit:
According to the docs for SendInput:
Quote
This function fails when it is blocked by UIPI.


UIPI is User Interface Privilege Isolation
« Last Edit: June 22, 2019, 08:16:36 pm by engkin »

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: Mouse and key input bug
« Reply #16 on: June 22, 2019, 10:47:23 pm »
It works like this:

1. The keyboard says: Key 9 has been pressed (KeyDown event).
2. The PC (OS) looks up what keyboard is attached and what the current input language is. It loads the corresponding code table and checks the state of the shift keys: Alt should be pressed as well.
3. It generates a KeyPressed event for keycode Alt-Tab.
4. This triggers the switch foreground application event, and now (for example) the Explorer/File manager is active.
5. The Tab key is released and pressed again, which generates the corresponding KeyUp and KeyDown events.
6. That last event triggers a new switch foreground application event, and the focus switches back to your application. This takes a while, and the user releases both keys.
7. Your application becomes active. And, because you're handling and decoding the keyboard yourself, you know for sure that the Alt key is pressed down (which it isn't). So all new key presses are handled wrong, until the user presses the Alt key and your application notices that it wasn't actually pressed.
« Last Edit: June 22, 2019, 10:50:41 pm by SymbolicFrank »

xinyiman

  • Hero Member
  • *****
  • Posts: 2256
    • Lazarus and Free Pascal italian community
Re: Mouse and key input bug
« Reply #17 on: June 25, 2019, 09:31:21 am »
In the end I solved my problem like this, I copy the text to the clipboard and simulate pressing CTRL + V so I avoid having to type the individual characters. Thank you for everyone's availability, you have been very kind :)

Win10, Ubuntu and Mac
Lazarus: 2.1.0
FPC: 3.3.1

engkin

  • Hero Member
  • *****
  • Posts: 3112
Re: Mouse and key input bug
« Reply #18 on: June 25, 2019, 09:45:16 am »
Well done! Nothing better than impressive simplicity.

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: Mouse and key input bug
« Reply #19 on: June 26, 2019, 05:46:59 pm »
In the end I solved my problem like this, I copy the text to the clipboard and simulate pressing CTRL + V so I avoid having to type the individual characters. Thank you for everyone's availability, you have been very kind :)

Only problem is that you destroy the previous contents of the clipboard, which may make your users unhappy. But if that doesn't matter ... :)
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

 

TinyPortal © 2005-2018