The µ-macro works mostly fine. So in an editor it will output the µ character and not cause any strange effects. But when running the macro in the search bar a few times after each other it will not output directly µµµµµ (and so on) as expected, but it will do “something” and for example show me a message. When continuing to press the related key (to trigger the macro) it will output the µ-character from time to time.
The macro to output the °-character does even more weird stuff. Depending on the application you are in it will either output the °-character, but by repeated use move the cursor back several characters (not a fixed number, but appears to be random). That is the case in the search-bar of Windows for example. When pressing the key when writing this message in the browser it will often not output °, but will leave this github-page and the cursor will jump to the search bar of the browser and append the °-character to the URL.
Here the macro for the degree symbol (just different numbers):
Thanks Max, I feel dumb. You need to make sure NumLock is on. That was the reason to activate it, but it should be tapped and not kept pressed. Reason behind keeping it hold was to make sure it is on. But one can seemingly not count on NumLock being on or off. That is often a setting in the BIOS. I have it off standard, but when you are using a computer where it is on that would kill the macro.
I guess there is no universal way for the UHK to know if NumLock is on or off? That is the main problem here. On Windows one can check that with a PowerShell script as it seems, but that would need to be fed back to the UHK…
But I now changed the macro to just press NumLock and that seems to fix the issues. Still strange that µ and ° macros behave differently, but hey – it works now. That’s what counts.
Thanks, but what does it do? It does not seem to check the system keyboard settings, which is what I am interested in. Regardless if NumLock is turned on the following macro will tapKey NumLock – and thus causing the exact strange behavior I was reporting (in case NumLock is on before running my character µ or ° macro.
ifNotNumLockOn
set backlight.constantRgb.rgb 0 255 0
tapKey numLock
I have now installed Keyboard LEDs, so I can actually see what the state of NumLock, CapsLock and ScrollLock is. That helped me to confirm that the UHK does not seem to really detect the NumLock state – at least not for me on Windows 11.
Strange. It’s supposed to work. From the reference docs:
ifCapsLockOn/ifNotCapsLockOn/ifScrollLockOn/ifNotScrollLockOn/ifNumLockOn/ifNotNumLockOn is true if corresponding caps lock / num lock / scroll lock is set to true by the host OS.
Like I said, only laughing, because I always seem to be stumbling over bugs. Partly possibly because I do not care really how others are “doing something”, but trying to find what works for me.
The UHK is great to a large extent, because you and László care! I had another keyboard which was good in many ways, but bugs I found where not fixed in many months (I doubt they are now)… Then basically everything falls apart.
