AutoHotkey Community

As it came up in the Scripts forum http://www.autohotkey.com/forum/viewtopic.php?t=3486 it would be nice to have an option (E) for the Input command that makes the EndKeys invisible, even if the input keys are visible to the foreground application. It helps when a HotString-like dynamic text replacement is performed. When the EndKey is Enter or TAB they usually cause complex results in applications, and to find and delete the matched input becomes impossible. If the script saves the EndKey in a variable it could be sent to the application after the text replacement has been processed.

Thanks. I've made a note to assess the difficulty of this. If it turns out to be easy, hopefully it will be done sometime in the next week or two.

This would also be useful for my script that assigns one special key followed by any keyboard key to produce many alternate characters or macro strings... accept and read and analyse any single keystroke into the running script. But Input with key limit and time-out gave me all but the invisible keys - thanks for the tip there. The Fitaly keyboard has a shortage of the invisible keys anyway - that was one reason for the script!

A related question: if no endkey is pressed for a long time (e.g. playing a game with letter key navigation), does the buffer of the input command grow indefinitely? If finally an endkey is pressed, the returned variable could be huge. I have not tried it, but I assume it slows down everything. It would be, therefore, also nice to have a rolling length limit for the input command: only the last, say 10 keystrokes are kept and returned. Of course, it only makes sense if the keystrokes are visible. In the referenced thread there is a workaround, storing each keystroke explicitly in a ring buffer, but with the rolling-length limit and the invisible endkey it would take just one AHK instruction.

It already limits the text by means of the L option. If you omit the L option, the buffer size is automatically set to 16383.

Due to the way the buffer is filled (simple append), there should be no slow-downs even when it gets large. The one possible exception is when you specify the * option along with a very long MatchList.

Edit: Input does not use a "ring buffer".

Chris, the help saysThis does not indicate a ring buffer. If the input command returns with Max, and we restart it, a possible match can be cut into two halves, and it won’t be found.

Also, according to the help text, if I press 16K keys the input command will terminate. If there is really a ring buffer, the help needs clarifications.

My mistake. Input does not use a ring buffer (I was thinking of hotstrings, which do).

The script should ensure that the 16,383 limit is never reached. I think this can be done in all but extreme/hypothetical cases by choosing one or more ending characters that occur reasonably often, such as Space or Enter.

The script should ensure that the 16,383 limit is never reached. I think this can be done in all but extreme/hypothetical cases by choosing one or more ending characters that occur reasonably often, such as Space or Enter.[/quote]Alternatively, test in Input1 for "Lasz" and in Input2 for "zlo". If found, investigate further. If not, do not.

A_KeyHistory would be more versatile. However, on reflection, we might need A_KeyHistoryRaw and A_KeyHistoryCooked, to trap "Lass{Backspace}zlo" also. We'd need to reset KeyHistory to empty (at least the local copy)... and the Lasz/zlo question doesn't necessarily go away. Never mind. Just give us the tool anyway so we can start to blame it for our own shortcomings

Me again by the way.