CODEWITHSUNDEEP
autohotkey
Christian
Christian

Reputation: 26427

When should `Sent` be used over `SentInput` in Autohotkey?

The Autohotkey documentation writes:

SendInput is generally the preferred method to send keystrokes and mouse clicks because of its superior speed and reliability. Under most conditions, SendInput is nearly instantaneous, even when sending long strings. Since SendInput is so fast, it is also more reliable because there is less opportunity for some other window to pop up unexpectedly and intercept the keystrokes. Reliability is further improved by the fact that anything the user types during a SendInput is postponed until afterward.

If SendInput is generally preferred, what are the use cases where sent is better in ahk? When does Sent win the Sent vs. SentInput decision?

Upvotes: 4

Views: 3931

Answers (2)

Java UseJoy
Java UseJoy

Reputation: 31

You should consider switching between SendPlay and SendInput only if you have problems with current setup. SendInput cause problems if you type while a long macro was activated. Your commands might be mixed with macro causing undesired behavior. Tutorial says that SendPlay is "not supported in older games", but I never had problems with that. Someone might comment "you haven't used AHK enough". Well, maybe.

Also, before switching from SendPlay to SendInput you should try to divide your macro into two. For instance, "save control group, do stuff, recall control group" fails in Starcraft2. Splitting it into Send "save control group, do stuff"; Sleep 10; Send "recall control group"; works.

Upvotes: 2

Ro Yo Mi
Ro Yo Mi

Reputation: 15010

I generally use SendInput, as I like the nearly instantaneous input. However I have encountered a few practical limitations:

  • Some applications like games do not like such fast key strokes because there may be rules against botting.

  • Some applications can't handle receiving keystrokes that fast and they just get bogged down.

  • I had an application that allowed pressing tab to move the cursor between fields.

    • When tabbing into a field the application needed time to acknowledge the arrival of the cursor before it would accept any input. The SendInput command was just to fast for this and frequently lead to mixed results
    • Pressing tab multiple times was also problematic, and frequently some tabs would be missed by the application and the cursor would end on an unexpected field.

  • SendInput is too fast to replay something for debugging. For example when I want to watch how the text is being inserted into fields on very complex forms.

  • In theory with Send you could insert a blob of text and randomly press and hold the shift button to increase entropy while the characters were being typed. Arguably I can't think of why this would be useful.

Upvotes: 2

Related Questions