Ctrl+Backspace workaround for Windows

[SunSerega]

Default TextBox behavior for Ctrl+Backspace is adding a broken character.

I used the basic idea from here but reconfigured it to work mostly like in the browser address bar. Though in my implementation more symbols considered stopping, including :. That's open for discussion.

The SO answer above linked one also mentions autocompletion somehow fixing this. But I wouldn't trust the idea of half-enabling one feature to get the other feature to work. And manual implementations give more control.

[HebaruSan]

Hmm, ctrl-backspace works fine for me already (on Ubuntu). I assume you're on Windows?

[SunSerega]

Yep, Win10x64. Also, it's broken for me in the official build and custom one without NetCore. Idk what about the custom build with NetCore, because I'm still figuring out what to do with this error:

Project '..\Core\CKAN-core.csproj' targets 'net5.0'. It cannot be referenced by a project that targets '.NETFramework,Version=v4.5'.

(this is after only recompiling CKAN-GUI project, using Debug_NetCore profile)

I guess all project files need to have the same <Choose> block as CKAN-core.csproj, but I'm even less sure why only I see this.

[DasSkelett]

Idk what about the custom build with NetCore, because I'm still figuring out what to do with this error:

The NetCore build doesn't build the GUI (WinForms isn't available for .NET Core, well, at least not for any OS besides Windows), only the CKAN-Core DLL (and the tests). It isn't really in use yet.

[HebaruSan]

I think this is what Mono does:

https://github.com/mono/mono/blob/78c2b8da29881eccda4c27ca7b2b7e9ed451c55f/mcs/class/System.Windows.Forms/System.Windows.Forms/TextBoxBase.cs#L1382-L1452

We should be consistent with this so Linux users don't have unnecessary changes with this update. Unfortunately that will mean key-by-key, case-by-case analysis...

[HebaruSan]

I looked into the history of ctrl-backspace a bit...

• https://devblogs.microsoft.com/oldnewthing/20071011-00/?p=24823

Supposedly it has never been a standard Windows keystroke, which is why Windows still likes to insert a literal DEL character into its text boxes to this day.

Rather it was a "rogue feature" borrowed from the Brief editor by some Internet Explorer devs for an autocomplete control they were implementing, which then spread app-by-app in response to requests like this one. When Mono came along, they implemented it standardly in their WinForms layer, which is why it has always worked nicely on Linux.

So nothing is broken and CKAN isn't doing anything wrong here, it's just not re-implementing a "rogue feature" that many other Windows apps and toolkits have implemented. But we can try to add it for better usability. I'm going to see whether we can somehow become an app that "uses SHAutoComplete [to] gain this secret Ctrl+Backspace hotkey." If that doesn't work out, I'll poke around at this branch a bit and try to isolate the Windows-specific code so we can be sure it doesn't break anything on Mono.

[HebaruSan]

I'm going to see whether we can somehow become an app that "uses SHAutoComplete [to] gain this secret Ctrl+Backspace hotkey."

This does it (in HintTextBox)!!

            this.AutoCompleteMode = System.Windows.Forms.AutoCompleteMode.SuggestAppend;
            this.AutoCompleteSource = System.Windows.Forms.AutoCompleteSource.CustomSource;

Wow, that is such a bizarre quirk, but it does allow us to tie into the "standard" ctrl-backspace handling that people will be familiar with, rather than having to review and maintain code with a bunch of for loops.

EDIT: This doesn't work if multiline = true, which we have for the abstract on the modpack editor. Everything else looks fine.

[HebaruSan]

Interestingly, some work was done in dotnet/winforms#629 to implement this at the library level, but a comment at the end of dotnet/winforms#259 states:

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

So I think we would need to compile the CKAN GUI for .NET Core instead of .NET Framework to take advantage of that. I didn't think that was possible for WinForms! Would the resulting binary work under Mono?

[DasSkelett]

So I think we would need to compile the CKAN GUI for .NET Core instead of .NET Framework to take advantage of that. I didn't think that was possible for WinForms!

Nope, WinForms support in .NET Core / .NET 5 is purely Windows-only, see the image in this blog post.

Would the resulting binary work under Mono?

No, Mono only provides an implementation for .NET Framework, not .NET Core/5.

The default publish output is a DLL with a, OS-specific and -native "launcher binary" that loads the runtime and then the DLL. My experiments with .NET 5 have shown that the launcher binary isn't strictly necessary to run the application, you can start it with dotnet <name>.dll. But that doesn't really matter anyway with WinForms unable to run on *nix.

But that's a bit off-topic for this issue, just want to say that we can't simply switch runtime and everything just keeps working as before.

[DasSkelett]

@SunSerega, what do you think about @HebaruSan's findings with the AutoCompleteMode and AutoCompleteSource options? Would you want to rework the PR to use those instead? It feels a bit safer than a subclass with a complex for-loop and custom key handling.

[SunSerega]

the AutoCompleteMode and AutoCompleteSource options?

I commented on this in the first message:

The SO answer above linked one also mentions autocompletion somehow fixing this. But I wouldn't trust the idea of half-enabling one feature to get the other feature to work. And manual implementations give more control.

That still leaves plenty of options. Having common implementation on mono and win would be great, but I don't have much time rn to properly dig into the 70 lines linked above. I can also make a simple if to use my Ctrl+Backspace implementation only on the win. Sounds bad, but at least better than AutoComplete hotfix (which also most certainly wouldn't be the same as Ctrl+Backspace on mono), and better than not doing anything. And I personally think it's best to think of ways of improving common implementation for win and mono, rather than looking for a minimal number of lines of change. But I realize, my perspective is by default skewed against legacy.