Author |
Topic |
|
YouraT
10 Posts |
Posted - 07/23/2013 : 04:06:14
|
Hi.
I'm not sure if this is an expected feature I don't understand, or maybe a bug....
In an application, I want a gesture to send the <ALT-A K> key sequence to active a menu item, as that's the only way to activate a particular command.
I've used:
acSendKeys("%a") acSendKeys("k")
What I'm noticing is that the key combination the application actually sees is different depending on whether the CAPSLOCK on my physical keyboard is active or not.
If it's active, the application sees what I expect, but if it's inactive, the application executes a different (valid) menu command that's accessed via the <ALT-E K> key sequence.
If I use
acSendKeys("%A")
instead, the behaviour is reversed - i.e. it sees <ALT-A K> when CAPSLOCK is inactive and <ALT-E K> when it's active.
Is this expected, and how could I get around it if so?
Thanks,
Youra. |
|
Rob
USA
2615 Posts |
|
YouraT
10 Posts |
Posted - 07/24/2013 : 02:50:50
|
OK - I can see that, and the work-around works perfectly - many thanks!
I'm curious as to the un-patched behaviour though.
A little testing with acSendKeys("Hello") into a plain text editor gives "Hello" or "hELLO" depending on the state of the CAPSLOCK key - not *quite* what I would have expected, but I guess following some sort of internal logic.
I don't quite understand though the translation of <Alt-A> into what appears as <Alt-E>...?
|
|
|
Rob
USA
2615 Posts |
Posted - 07/24/2013 : 09:28:17
|
Not sure about the ALT key confusion. Just to be clear, I didn't write the SendKeys code, simply plugged it into S+ from a CodeProject project. I've found a couple bugs in that code in the past, but in the end it saved me a lot of time! So while it may have its oddities, overall it has worked pretty well =)
However, it means that I can't defend or easily explain the inherent logic as I didn't write it. |
|
|
|
Topic |
|
|
|