MouseAndKeyInput ---> To this "new" LazHIDControl

[Tony Stone]

A couple years ago I began working on and extending the LazMouseAndKeyInput package, and with some help from Claude AI, I finally got a bunch of bugs worked out. It's called LazHIDControl... I had to rename it and start a new project as using the included LazMouseAndKeyInput package kept interfering with my existing applications so it was easier to start something new.

What it does:

• Mouse and keyboard automation across platforms
• Global hotkey registration (CodeBot Library I once found showed me how to do this)
• Works on X11, Wayland (GNOME/KDE), and Windows

I would occasionally see posts here about automating keyboard/mouse control, and a few years ago the existing package wasn't cutting it - I had to rely on xdotool. Now my projects work without xdotool on Linux Mint, and even the Windows builds work (though Windows needs more testing - I've had occasional issues).

  Fair warning: Since Claude helped me fix a lot of bugs, it's probably f##k#d up in many ways! But it's working well enough for my use cases and I hope it will be helpful to others.

GitHub: https://github.com/TonyStone31/LazHIDControl

  If anyone's interested in testing, contributing, or just needs cross-platform HID automation, check it out. Wayland(must be a better way?) and macOS(I dont have a machine to test with) folks especially welcome!

[n7800]

Is this a copy of the project? Which one is more current? Is it possible to hide the redundant one so users don't get confused?
* https://github.com/TonyStone31/LazHIDControl
* https://github.com/TonyStone31/lmakiproject1

[Tony Stone]

Ahh yes n7800, I forgot I did the lmakiproject1 git repository.  That was back when I first started "fixing" it.  I will delete that old one...   This new one is polished and has direction etc...

[n7800]

Maybe it's worth adding ssMeta/MOD_WIN here as well?

I'm speaking from memory, but as far as I remember, it worked.

[n7800]

I don't know if something similar is needed here. I haven't used this feature before.

[n7800]

I haven't tested it, but judging by the code, "TWinKeyInput.capsLockRestoreState" won't always work. For example, in my OS settings (standard Windows, not external applications), CapsLock is only reset by pressing [Shift]. Pressing [CapsLock] key again won't reset it.

I don't think this can (or should) be fixed, just something to keep in mind.

[Tony Stone]

Yeah I am not certain I tested that all on Windows.  I do remember my intentions of dealing with a Caps Lock key on were so the PresString function could still accurate type a string.... I think the solution is actually simple...  just "invert" the requirement for the Shift key.  If Caps Lock is on then Shift is required to type lower case letters.  If it is not on then shift is required to type upper case letters.  I will have to think about that.  I think it is more important to have a string "re-typed" accurately than trying to restore the caps lock state.  Going to play with that now!  At the moment I have 1 Windows machine available to play with.

[Tony Stone]

I misunderstood what you were saying...  So after reading again.... hmmm.  I never had a system that required me to use the shift key to change the CAPS lock state.  So that is something new to me.  But I think a work around could be implemented for that.  Could be as simple as trying to set the state, check it, if it failed to set try to set with Shift. 

[Tony Stone]

And on my X tests toggling the CAPS lock off and on was actually a hacky solution however it allowed automating unicode input so my tests would always pass.  However after implementing Shift Key requirement based on CAPS lock state I cannot automate entering the unicode characters now because If CAPS Lock is on X will not allow me to enter a unicode char with Shift+Ctrl+U.... so yeah there is no perfect solution when it comes to CAPS lock.  So when it detects a unicode Char now it will have to keep doing it the old way of toggling the CAPS lock off and restoring and for ASCII characters it can decide when to use the Shift key for upper/lower case based on CAPS Lock state.... hmmmm

[Tony Stone]

I sorted out various issues for Windows and CAPS Lock handling.  If anyone has some free time and wants to do a few tests or experiments and report back any issues I would love to try and sort them out.  Once we have fairly reliable cross platform handling of key and mouse input I want to start bringing in a bunch of Window handling functions I have in various programs into a nice neat package.  Getting Window geometry and all that fun stuff...

On a side note, I have been toying with the idea of getting a Mac machine specifically to try and get some of my programs to work on Apple systems.  Anyone here have a recommendation for an affordable Mac system that would be good for testing Lazarus FPC programs.

https://www.ebay.com/itm/336259374759?chn=ps&google_free_listing_action=view_item

wonder if this would be good enough and make sense.  I think it is ARM based....

[af0815]

I haven't tested it, but judging by the code, "TWinKeyInput.capsLockRestoreState" won't always work. For example, in my OS settings (standard Windows, not external applications), CapsLock is only reset by pressing [Shift]. Pressing [CapsLock] key again won't reset it.

On a german system and keyboard in Win 7/10/11 i have to use capslock to toggle the capslockstate. Pressing shift alone ist not resetting the state. The same in Linux (Mint). Computer only with a texteditor.

[n7800]

af0815, this isn't the default behavior - I specifically configured it in the Control Panel (I'm not sure what it's called in other languages). I don't know if this even exists on Linux.


Tony Stone, because of these complications, I assumed the solution wasn't worth it. Besides, I think this is a rare setting, and perhaps no one will encounter it. I like it because I don't have to remember or learn the [CapsLock] state, and I can touch-type.

In any case, the main thing is to document the behavior, whatever it is.