AutoHotkey Community

[ description ]
It sends characters or "emulate" physical key input, converting and sending the text through postmessage.

Usage:

Please read the example section (at bottom) and the following notes:

0x102 corresponds to WM_CHAR. Its possible to use 0x100, which is WM_KEYDOWN, to emulate physically key down press. If you opt to use it, note that only [a-z],[0-9] characters will work for the text conversion. For the other symbols, use as reference: http://msdn.microsoft.com/en-us/library/ms646280.aspx

[ function ]


[ example ]
Usage:
After loading the script, choose a field of input (eg: notepad) clicking on it, then press F1. Once F1 is pressed, the window can be hidden and the script will keeping sending the message (like controlsend behaviour)


Thanks Titan for the loop fix :)

_________________
                                  [ profile | ahk.net | ahk.talk ]

Thanks, this will be very useful to me. I've simplified your function a bit:

_________________
GitHub • Scripts • IronAHK • Contact by email not private message.

ive write this for lazy people and for the newcomers...
not for u titanz, go finish rusty common'! :P

_________________
                                  [ profile | ahk.net | ahk.talk ]

What are the benefits of this over ControlSend? I guess sending WM_CHAR may work in some instances where ControlSend doesn't, since ControlSend only sends WM_KEYDOWN and WM_KEYUP. Otherwise, I would think ControlSend would be easier and more efficient. (Did you know it uses PostMessage internally?)

1- some inputs don't need WM_KEYUP (it would cut some time and would be theorically faster than controlsend), forcing the user have more control over the WM.
2- controlsend can't hold key presses for a long time
3- more control over keyinput order, don't need to sleep
4- controlsend can't send mouse clicks

_________________
                                  [ profile | ahk.net | ahk.talk ]

Your theory doesn't take into account the overhead of script. The script may be "much" slower, although the target window might spend less time processing the messages. Then again, if the target doesn't need WM_KEYUP, it isn't likely to take long processing it.
What does your script offer that {key down} .. {key up} does not?
Could you give an example? I don't see how your script has more control than ControlSend, why ControlSend would need sleep, or how your script removes or satisfies this need.
Your script cannot mix key-presses and mouse clicks, so it would be logical to include ControlClick in the comparison.

So are you alleging that ControlSend and Postmessage would have the same effect? Experimentally postmessage benchmarks doesn't shows that. There is even a slightly difference between sendmessage and postmessage (it shouldn't have such difference, don't ask me why, go test it).


Users want to hold keys like ctrl, alt, shift, space for long time and press simultaneasly other keys, ControlSend can't handle that. Even with {key down}{key up} ControlSend can't hold keys for a long time. Try it by yourself and see the results, users have been reporting this a long time and no one cared about it.


When you input a lot of text data through controlsend, if you try to send {enter} after them, it would require a sleep because the enter key is sent before the text message completes. This problem was reported by some users too.


PostMessage is a command with more broad usage capability, there is nothing illogical on that.

_________________
                                  [ profile | ahk.net | ahk.talk ]

Since you ask, I assume you didn't know ControlSend uses PostMessage. It posts WM_KEYDOWN and WM_KEYUP messages.
PostMessage does not need to wait for the target window to process the message. SendMessage does.
Perhaps for modifier keys this is the issue:

For other keys, ControlSend posts WM_KEYDOWN/WM_KEYUP messages. In theory, the only way it could fail is in the target window's processing of the messages/handling of keyboard state.
It's the first I've heard about it.
ControlSend doesn't post the message for a key until after the message for a previous key has been posted. Therefore, I suspect the target window's handling of the messages.
I was pointing out that your function can send only a single type of message with any given call. If it could send both keystrokes and mouse clicks in a single call, that may be an advantage over ControlSend/ControlClick. Since it can't, your argument that ControlSend can't click is pointless, as a user can easily ControlClick.


The main reason for my posts is that you say the function is intended for lazy people and newcomers, but I cannot see how it could be easier, quicker, more intuitive or more effective. I say lazy people and newcomers are better off sticking with the built-in methods.