AutoHotkey Community

[ef666ef]

I have searched the forum and read the docs, but still must have missed something fundamental. When remapping shift to space and then remap shifted characters with

[Chris]

This is by design even though it causes undesirable behavior in this case. The reason it does this is that the program assumes that when you do Send {Shift down} that you want it to stay down for each subsequent Send command.

There is a more pure remapping feature planned for the future that might solve this. The syntax might be something like Space::Shift (where Space becomes the Shift key). Until then, one work-around is to change your hotkey(s) to release shift prior to sending:

+q::send {Shift up}b

This might produce other side effects, which in turn might have other work-arounds if needed.

[Guest]

Hmmm, strange design decision. Considering shift's current behavior, it seems more logical and consistent to think the opposite way. That is, when sending shift down you would expect the same behavior as if the real shift is held down - not to modify an existent statement against the scriptwriters explicit intention. Holding real shift down after

+a::send q

and pressing 'a' will produce 'q' as expected. That's logical (I thought that was one of the main purposes of the + prefix). Now, after a send {shift down}, pressing 'a' produces a capital 'Q' on the contrary of shift’s behavior and despite the fact that I explicitly stated that key combination to produce a 'q'. This feels unlogical and inconsistent. The very purpose of remapping is to control the exact behavior of a key press including the modifiers. Am I thinking wrong here? What is the advantage of this approach?

[Chris]

[Guest]

Ok, I get it. Hope I didn't sound too critical. AutoHotkey is a truly great application! Would be great if the remapping feature mentioned was implemented also of course. Thanks for the answer!