What is the difference between SendKeys wait argument false or true

Question

Following link explains what is the difference between SendKeys wait argument false or true.

Wait Optional. Boolean value specifying the wait mode. If False (default), control is returned to the procedure immediately after the keys are sent. If True, keystrokes must be processed before control is returned to the procedure.

https://learn.microsoft.com/tr-tr/office/vba/language/reference/user-interface-help/sendkeys-statement?f1url=%3FappId%3DDev11IDEF1%26l%3Dtr-TR%26k%3Dk(vblr6.chm1009015)%3Bk(TargetFrameworkMoniker-Office.Version%3Dv15)%26rd%3Dtrue

But I dont understand what that means.

Here is the first code:

Sub Macro1_ForFalseExample()
 'If False (default), control is returned to the procedure immediately after the keys are sent
 Range("A1").Select
 SendKeys "Fruit Name", False
 Range("A2").Value = "Apple"
End Sub

Here is the second code:

Sub Macro2_ForTrueExample()
 'If True, keystrokes must be processed before control is returned to the procedure.
  Range("B1").Select
  SendKeys "Car Name", True
  Range("B2").Value = "Toyota"
 End Sub

I cant see any difference when I run the codes above.

Answer 1

With SendKeys it can be helpful to think of the wait argument is giving you the option of SendKeys operating synchronously (wait=True) or asynchronously (wait=False). It is of course not quite that simple but it can help to understand that implications.

using wait=True does not wait for the user to press any keys as some of the other comments have suggested, it simply waits for the program to finish processing the key press message before returning to your code, SendKeys is not part of the excel API and

If the message is simple and has no processing overheads, then you will not notice the difference between True or False. Both will appear to return immediately.

A good default is to send True unless your code specifically needs to continue processing without waiting for the message to be received. The only side effect of this is that your code will pause momentarily and wait for the program to respond. Think of this as giving the application time to react to your message. Send Keys is generally used to initiate keyboard shortcuts or to automate user interfaces that do not have an API, as such usages of SendKeys might initiate long running processes or start external programs and you might not want to wait for them to complete before you continue, that is when you send False.

When automating Excel, SendKeys is generally discouraged and you should use the API in all places that you can, reserve SendKeys for scenarios where you really need to simulate keyboard entry.

If you need to set a cell value, then you can do that with the Value property on the Range, but you are already doing this. in your examples.

A common example where wait=True matters is when using copy ^c or paste ^v with large ranges. These take time to process and you would want that operation to complete before the next line of your code executes. otherwise if your next line of code tried to select another range, you might find that the application has hung or if your code tries to paste before the copy operation has completed it might paste the previous captured content, or nothing at all.

If you have no follow up code after SendKeys, then it is irrelevant if you wait or not, in this case wait=False might give the impression of greater performance because your code will continue executing immediately.

As with all learning, if you are unsure, try to experiment this post is trying to explain why the wait parameter exists, if you choose to not wait and then experience unexpected outcomes, try with `wait=True

The general implication of waiting or not is that the application might have key event handlers logic that takes time to execute, in some cases the application might even prevent processing. If your logic checks the UI after SendKeys then you will always want to use wait=True.

Take the example from the MS VBA Reference that is automating the calculator:

Dim ReturnValue, I 
ReturnValue = Shell("CALC.EXE", 1)    ' Run Calculator. 
AppActivate ReturnValue     ' Activate the Calculator. 
For I = 1 To 100    ' Set up counting loop. 
    SendKeys I & "{+}", True    ' Send keystrokes to Calculator 
Next I    ' to add each value of I. 
SendKeys "=", True    ' Get grand total. 
SendKeys "%{F4}", True    ' Send ALT+F4 to close Calculator. 

If you did not wait for the application to finish processing the key press your code might run faster than the UI and could result in the UI missing some of the key press messages. If all of send keys worked then you should get an answer of 5050. Imagine that the calculator needed 300ms to process the messages, some or all of the messages might be missed if your loop logic operated faster than that.

Calculator is no longer a good real example of the UI lag, many years ago you could make it skip in this way, so I'm probably showing my age, but this is more an example to help you identify potential issues in logic if SendKeys missed some messages.

Calculator is still a good example of why you might use SendKeys because in this context we do not have access to an API to automate the interface, instead we are relying on keyboard commands/entry alone.

SendKeys is not a universal queue, if the application is not ready to receive input then the message will be ignored, wait=True means that you want to allow the process in focus to take the time that it needs (if it needs any) to complete the operation before you start sending more key commands.