Question

I found an article here:

Winforms Textbox - Using Ctrl-Backspace to Delete Whole Word

to delete the whole word in a textbox while holding ctrl+backspace, but I noticed that if you don't implement the app.config modifications like so:

<configuration>
  <appSettings>
    <add key="SendKeys" value="SendInput" />
  </appSettings>
</configuration>

that only the current word will be removed and the process of backspacing will be interrupted. For instance, if I typed in "Tim tom" and then used the ctrl + backspace trick, "tom" would be deleted, interrupting any backspace operation and leaving "Tom ".

If you do use the app.config modification, however, "tom" would successfully be removed and backspace operations would continue, but without continuing to remove whole words, as if you were just holding the backspace button.

Does anyone know what causes this or how to fix it?

Was it helpful?

Solution

Your application is choosing a different behavior of sending keypress equivalents to the application.

The historical exposition why the two protocols exist is explained here:

The SendKeys class has been updated for the .NET Framework 3.0 to enable its use in applications that run on Windows Vista. The enhanced security of Windows Vista (known as User Account Control or UAC) prevents the previous implementation from working as expected. The SendKeys class is susceptible to timing issues, which some developers have had to work around. The updated implementation is still susceptible to timing issues, but is slightly faster and may require changes to the workarounds. The SendKeys class tries to use the previous implementation first, and if that fails, uses the new implementation. As a result, the SendKeys class may behave differently on different operating systems. Additionally, when the SendKeys class uses the new implementation, the SendWait method will not wait for messages to be processed when they are sent to another process.

The timing issues mentioned here concern especially continued control of application by characters, not just one character at a time. They include

  • difficulty in synchronizing typing rate
  • making sure that the right window receives the input when the app is opening dialogs
  • making sure that the right app receives the input even when the user meddles with close buttons

However, the real reason between the SendKeys behavior change was not programmer friendliness (which did not improve significantly), but security.

It is definitely a good idea to set the SendKeys parameter to specify the desired behavior. You don't want your application to mysteriously start behaving differently just because UAC was turned on or off.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top