Winforms: Create proper Ctrl+Backspace shortcut in TextBox

[ArrowCase]

In Windows, Ctrl+Backspace commonly serves as a shortcut to delete the word immediately preceding the cursor. It is equivalent to Ctrl+Shift+Left followed by Backspace.

In WinForms, this shortcut works only in single-line TextBox controls which have autocomplete enabled. This is actually built into SHAutoComplete somewhere in the win32 API, and is a "rogue feature" with no documentation (some history here). If the TextBox is multi-line or doesn't have autocomplete on, Ctrl+Backspace inserts a DELETE character (ASCII 127) instead.

Note: The Ctrl+Delete shortcut (which deletes the word following the cursor) works in all relevant WinForms controls.

Outside of WinForms, the Ctrl+Backspace shortcut is nearly ubiquitous on Windows (as of October 2018, even Notepad finally has it!). As such, I propose properly implementing it in WinForms controls such as TextBoxBase and ComboBox with a custom handler for Ctrl+Backspace.

---

I've submitted a PR with one approach to add this shortcut, namely using SendInput sending native messages to simulate the aforementioned Ctrl+Shift+Left, Backspace keystrokes. I believe this is the right approach — as even the current autocomplete TextBox "feature" seems to be selecting the text and then deleting it if you watch closely.

Another possibility would be to use internal text selection functions rather than sending keystrokes. However, that requires replicating the logic dealing with word boundaries/punctuation currently used by Ctrl+Shift+Left, which is a bit quirky, not to mention wildly inconsistent between different Windows programs. We can consider this approach if the current PR is lacking.

[zsd4yr]

My guess is that this is going to be by-design. I am fairly certain that the textboxes in winforms are wrappers around native and that winforms doesn't handle text at all except to send it to the windows control.

[ArrowCase]

@zsd4yr WinForms has a custom "select all" shortcut handler for multi-line TextBox controls here with a comment explicitly calling out the intent to support something that the native control doesn't.

/// Native "EDIT" control does not support "Select All" shorcut represented by Ctrl-A keys, when in multiline mode,
/// and historically Winforms TextBox did not support it either.
/// We are adding support for this shortcut for application targeting 4.6.1 and newer[...]

[zsd4yr]

Good to know there is precedent for this; that makes the bar lower. Someone on the team should probably go into our previous source control and attempt to ascertain the reason for / work item associated with that change.

[jnm2]

I live by Ctrl+Back/Del/Left/Right. It doesn't have the awareness of users and implementors that it should have for how much it improves quality of keyboard usage.

[zsd4yr]

What happens when you perform this operation on a native multiline text box?

Trying to determine if this is something windows forms might want to handle on our end or if this is something Windows might want to look at.

[ArrowCase]

@zsd4yr It will insert the ASCII DELETE character, which shows up as a box.

It would be fine by me if the Windows team wanted to make this change, but I will note that essentially every text box in Windows 10 today already has the Ctrl+Backspace behavior I'm proposing (try it out in the search bar). Whether that's because they don't use the same underlying native control as WinForms does, or because they use the autocomplete hack, I don't know.

[merriemcgaw]

Can you please let us know what testing you plan to do to ensure there are no regressions in the TextBox after your proposed change?

[ArrowCase]

@merriemcgaw I have tested the behavior of the shortcut in various possible scenarios -- position of the cursor, whether or not a selection already exists, whether the user is also holding other keys including modifier keys, etc.

I'm still planning on doing some testing to see if there are potential race conditions with the way keystroke messages are being sent. For example, if Ctrl+Backspace is immediately followed by a bunch of arrow key presses, is the Ctrl+Backspace handler guaranteed to complete before the cursor moves somewhere else? Or if the user tabs immediately into a different control?

Once functional testing infrastructure exists in this repo, those kinds of tests would be worthwhile to adapt into it.

[KlausLoeffelmann]

If I understood this proposal correctly, I would be worried about breaking changes in existing code. So, if we at all considered this (where I have to say, I'd actually like the idea), we should definitely also consider quirking it. I therefore find it better to also create an issue in which we thematize quirks as such.

[ArrowCase]

@KlausLoeffelmann To make sure we're on the same page, what kinds of breaking changes would you expect? Wikipedia says the ASCII DELETE character historically never had any use on Windows, so I can't imagine why anyone would be relying on the old behavior of the shortcut in WinForms.

For most people, if they know about the other behavior at all, it's because they tried to use Ctrl+Backspace as a "delete word" shortcut in Notepad, and then were confused by the strange box that appeared instead.

[nsivov]

@ArrowCase underlying window handles are exposed in winforms, it makes subclassing easy (unless it's somehow remedied at winforms side, but I doubt it). With subclassing any change to existing behavior is immediately visible, in your case new message sequences sent to the Edit that were not sent before. Also isn't it trivial to have the change you're proposing as a custom control, based on winforms TextBox?

More generally speaking, and maybe I missed it, why such enhancements are considered at all for .NET Core? What's a point of making behave differently from .NET Framework?

[ArrowCase]

@nsivov The point of this change is to improve WinForms. I don't see why enhancements wouldn't be considered. The goal for the 3.0 release is parity with netfx, but as the readme states, "Over time, the two implementations may diverge."

[nsivov]

That only means that no promises is made that they will not diverge. But it would be interesting to hear official interpretation, and attitude towards deliberate changes in behavior.

[BlueEnni]

In desktop shortcuts the box still appears after pressing ctrl + backspace

[RussKie]

In desktop shortcuts the box still appears after pressing ctrl + backspace

This change is only available on .NET Core/.NET. .NET Framework is feature complete, and won't be enhanced further.