AutoHotkey Community

the post above is not mine ! Probably Chris one ! I effectively posted a new example in witch "Send ^c" was surronded by "BlockInput, on" and "BlockInput, off" to be sure that the clipboard content is send without any interference. That sample was demonstrating that there was no lost of physically typed keystrockes, even with a very big clipboard content, with this method (at least on my computer !!!)...
And I said too that I think it would be good to be able to record phsycally pressed keystrokes during a Send command to be able to decide what to do with them after.

Look, I am a newbie to AHK, and just interested in basic scripts, not fancy windows programming, and I don't know the technical architecture of AHK or of programming an application like this in Windows, nor the philosophy behind AHK, BUT - I still think there should at least be an option to simply QUEUE UP all keystrokes entered during a script, or at least during a SEND, and send them when the script finishes. It seems to me this is the intuitive way for it to work. Maybe that's impossible architecturally, but it sure would be nice!

Just my 2 cents.

Dan
The one who started this thread.

Improvements in this area area planned. Hopefully one of the suggested solutions will work for you in the meantime.

Yes, I killed it by accident. I think I pressed the wrong button and wound up editing your post rather than quoting it. If you happen to have a copy of your clipboard script, feel free to repost it. Sorry for the inconvenience.

Here's my original reply to your missing post:I think such a thing is too elaborate because the vast majority of hotstring users just want their abbreviations to expand quickly and reliably. In other words, I think that making a buffer of physical keystrokes available to the script would not be needed often (and in cases where it is, you could use the Input command).

Never mind. I didn't kept a copy of my script, but it was so simple... To be complete for kronhead, the last version of my solution was :
If you type "ccc", the string is send, and if you type "cccc", you don't loose the last "c", even if the text in the clipboard is very long (longer than in the example). What you type physically during the Send command is not buffered, so you may loose it, but as Windows think that the send of the clipboard content is the send of only one character, the send is done very fast. You can try my solution with a very long text in the continuation section (see this subject in the help file).
Of course the solution works with a very short text too !!!
It you do for example : and you type "dont go to the ...", you will have "don't go to the ..."
Hope it helps

@ Chris : 1- "would not be needed often" ? May be, I'm not conviced. I think that if the user have this possibility, he will use it to avoid the lost of characters typed by the user during a Send command, rather than block the user input and loose the physically typed characters.
2-Could you post and example of what you have in mind with the Input command, please ?

That's interesting. But rather than making it a built-in variable, I think this feature could be built into the program as a default (assuming it's feasible). For example, if the user physically types something while the Send command is sending long text, those keystrokes could be buffered and automatically sent afterward.

Due to the slight possibility of this breaking existing scripts (such as those that intentionally use a high key-delay), perhaps this behavior could be made optional somehow.

However, there might be complications when both the Send command and the user try to send keystrokes at the same time (e.g. if both the script and the user are trying to use the Shift key simultaneously). So I've made a note to research it more.

Thanks for the idea.

The Input command has an option to ignore keystrokes generated by AutoHotkey. With that in effect, it might be able to capture the user's physical input even during the Send command. However, it's not designed specifically for that, and due to time constraints I haven't yet tested it.

I think it would be better to let the programmer decide to keep or delete the characters typed physically during a Send command, even if there were no way to exam them.

I didn't remember the option. But I think that the difficulty would be a speed one. the Send..ing of character can be fast, as slow to allow physically typed characters to "interrupt" the Send...ing process, but may be too fast to not allow the intercept by the Input command.... (I hope I can be understood)

Hopefully something will be devised eventually that will provide an improvement in this area (hotstrings and Send). Until then, using -1 for KeyDelay and setting the priority of the script to High are pretty good solutions for those rare cases where keystrokes don't get sent fast enough.

As for the Input command, if you ever find it inadequate for some buffering task you had in mind, please let me know. But as it stands now, improvements to it are a fairly low priority.

I was the original poster - and I can certainly use it successfully with these changes. Occasional clitches are minor.

Just FYI - I switched to AHK to replace Activewords (I was trying to remember the name earlier and could NOT for the life of me - then I got an email from them today.) Activewords was big and slow, but I never had the problem of mixed keystrokes/script characters when I was using Activewords. But I am still happy I switched.

Dan

I second that!

I use Autohotkey to easily input characters with a macron (horizontal line):
[code]:*z?:ää::
PrintUnicode("Ä

For those still interested:

Buffered Send and SendRaw

Hi shimanov,

thank you!

I don't understand your script yet, but I'll give it a try!

Regards,

Laudrin

Finally, a response. I was beginning to think it didn't work as intended.

At the moment, I'm writing my thesis (Staatsexamen). So there's little time for me to try out any scripts or write in the forum. Even if it's hard because there are lots of old and new interesing scripts...

From wednesday on, after I handed in my work, I will try to implement your buffered send solution in my script. Then I will give you a feedback. But I'm sure I'll have a lot of questions then.

Regards,

Laudrin