SetKeyDelay removing duplicate characters

[Knee]

I'm trying to automate some find commands and I stumbled upon double underscores being printed as single underscores:
this__is__a_test -> this_is_a_test
or
this++is++a+test -> this+is+a+test

ahkerror.PNG (1.15 KiB) Viewed 1872 times

Text was sent to a MINGW command line (running on Windows 10)

When I removed the SetKeyDelay, 0 then everything was printed as expected.
Displaying find_cmd in a MsgBox prints the correct number of duplicate characters.
Displaying clipboard in a MsgBox prints the correct number of duplicate characters.

Code: Select all

$F3::
SetKeyDelay, 0
find_cmd := "find . -name " . clipboard
WakeupWindow("MINGW")
Paste(find_cmd)


WakeupWindow(str)
{
    IfWinNotActive, %str% ; explorer
    {
        WinActivate, %str% ; explorer
    }
}
Paste(str)
{
    SendRaw %str% ;SendRaw did not make much of a difference vs Send
    Send {enter}
}

Is this a bug or something I'm misunderstanding about 'SetKeyDelay' ?

[joefiesta]

1. The code you have submitted, while it works, does not demonstrate your problem.
In your sample code, you have not placed anything on the clipboard, and so whatever I (the tester) have on my clipboard is what is pasted.

You need to include your code that placed whatever it is that is giving you a problem on the clipboard.

2. You talk about characters being "printed". What do you mean? There is no PRINT command anywhere.

[Knee]

Assumptions for this program's execution:
• "this__is_a_test" is on your clipboard
• a command line window whose name contains "MINGW" is open

1. The code you have submitted, while it works, does not demonstrate your problem.
In your sample code, you have not placed anything on the clipboard, and so whatever I (the tester) have on my clipboard is what is pasted.

See above for sample text:

this__is_a_test
this++is+a+test

You need to include your code that placed whatever it is that is giving you a problem on the clipboard.

See the code above.

2. You talk about characters being "printed". What do you mean? There is no PRINT command anywhere.

Characters being displayed on a screen is what I call 'printed'


Here is a demonstration of the problem:
"this__is_a_test" is currently on the clipboard before running the program

This is the entire snippet that's running

testpaste_snippet.png (16.13 KiB) Viewed 1770 times

[section]
Execution:
[/section]
1. Running the script (as administrator)

testpaste_snippet2.png (5.79 KiB) Viewed 1770 times

2. Pressing the specified hotkey (F3)
3. Recording results:
The MINGW window is opened

testpaste_snippet3.png (18.5 KiB) Viewed 1751 times

There is a difference in expected and actual result:
actual: this_is_a_test
expected: this__is_a_test

[lexikos]

A short delay (sleep) is done automatically after every keystroke sent by Send or ControlSend. This is done to improve the reliability of scripts because a window sometimes can't keep up with a rapid flood of keystrokes.

It stands to reason that if you reduce the delay, you reduce the reliability.

The purpose of SetKeyDelay is to allow the script to either increase the delay when the target application is unreliable with the default setting, or decrease the delay when you want to send keys faster. If the target application cannot keep up, that is the cost you pay.

Console windows handle keystrokes a little differently to most Win32 controls. There are more reliable methods of sending text to a console window, such as the Console API (obsolete) or Text mode (recommended).

A common technique is to modify the Clipboard and then paste. This is generally faster and more reliable than any other generic method of sending text. Since you're on Windows 10, Send ^v should work with the console window; but on all versions, you can use (or automate) the Edit, Paste menu item. You can restore the previous Clipboard content afterward, but in that case you must allow a delay for the target window to finish pasting.

[Knee]

Each time the script runs it's always the case that these "+" or "_" duplicate characters are the ones that never make it. I would be convinced of SetKeyDelay, 0 being too fast if other characters were to go missing as well.

[lexikos]

With the smallest possible delay (a setting of 0), the result is incorrect. With a larger delay, the result is correct. The only difference between the two settings is the length of delay. 0 is therefore too fast.

That "a window sometimes can't keep up with a rapid flood of keystrokes" is not the only explanation for why a delay might be necessary; just the easiest and most generally applicable one. An application might discard buffered keyboard events at times or handle them differently depending on timing. Handling of different keyboard events generally implies performing a different function, which means executing different code, and perhaps taking a different length of time to do it.

If you are typing into a console window and your input is merely being buffered and displayed, one might think that any given printable character should be handled equally; but something must be causing the difference, and I am confident that something is not AutoHotkey. By process of elimination, I assume it must be MINGW, console window keyboard handling, or some external factor I am not aware of. Have you tested with a different console application or GUI application?

I have reviewed the code used to perform key delays and confirmed that it does not in any way differentiate between keys. Different characters may require a different combination of modifiers, but by default (PressDuration is -1) these changes in modifier key state do not cause a delay. There is no special handling for any given character in the Raw mode, or for "_" in any mode.

Putting aside whether this is a "bug", I believe there is nothing that can be done to work around the issue other than the mechanisms already available to you: increase the delay or try a different method of sending text (clipboard-paste, Send {Text}, ControlSend, ConsoleSend(), ...).

SendRaw did not make much of a difference vs Send

If you used Send %str% rather than Send {Raw}%str%, there would certainly be a difference. Without Raw, this++is++a+test would rightly produce thisIsATest, since + means Shift.