Thank GOD, thy finally fixed this:
“To match properties, use As instead of as when showing method return types in the Navigator.”
Oh it was so horrible to see “as” instead of “As” all these years! 
Seriously, though, it’s nice to see some cleanup of the IDE, including some truly nasty stuff like deletion of things in the Navigator if forward-delete is hit in the search field.
If it wasn’t for having to prefix everything with “desktop”, I’d renew my license.
I do not case because this key does not exists on my conputer (laptop)… 
I get your pain. Thankfully, this key is on my keyboard. A requirement for me 
depending on the laptop the fwd-delete is fn-delete
Or the totally random CTRL+H for delete, which is a common shortcut for replace in other apps.
Not random.
Backspace key is chr(8) and control-h is a way to press that as H is the 8th letter of the alphabet.
Yes, but was the bug there too ?
ps: fn-Return = Enter (yes, I use this one often)
Random by virtue that its not listed anywhere in the ide as a shortcut and so shouldn’t trigger.
Dont think the TextInputCanvas even can tell the difference between the Backspace key and Ctrl-H. At least not unless it reads the physical keyboard key code, which I dont think it does, they both appear “the same” to it.
And reading key codes is problematic at any rate since they vary simply by physical layout
The C source is all on Xojo’s GitHub account
In that regard I think Christian is correct about why it works the way it does
Try things like Ctrl-M → Chr(13) which should be a CR
Ctrl-J which should be a LF
Something must be able to tell the difference because you can can rebind CTRL+H to something like open “What’s New in Xojo”. Now it does that instead of causing the deletion of something in the nav when I hit CTRL+H. The fact that I can rebind CTRL+H to something else shows that Delete and CTRL+H can do two different things. If CTRL+H is unbound, it should throw the press away and not pass it on to the Delete handler.
the OS figures that out and passes a event saying to invoke the menu code for that ever item
once it gets to TextInputCanvas its “just another character”
I dont think TIC handles it quite that way so it sees “a character” - basically a backspace
There may even be code internally in the code editor implementation that supports Emacs style key bindings
It existed at one time so things like mark & yank worked and they used things like ctrl+M, ctrl+Y and several others
but I dont recall all those
file a bug report and see what happens 
oh and macOS and Windows MAY be different in their handling of menus as well
macOS can have menu short cuts with NOT meta keys (cmd, ctrl, shift, alt)
I dont think Windows supports that
I doubt that factors in to this at all but could in some scenarios
Deja Vu
https://tracker.xojo.com/xojoinc/xojo/-/issues/46714
Accelerator tables in windows can handle and differentiate between all key combinations either by virtual-key code or ascii depending on what you want to handle which include modifiers.
Sure I have no doubt that set up right that it can be done
Makes me think that in some places they dont have a menu handler set up
And others they do so in some places it IS just a backspace as Christian said way way back
No need to debate this endlessly since you and I cant alter the code
Only Xojo folk can