Question : Ascii code showing in text editor

[jonghewk]

If I press "ctrl + keys" (ex. ctrl + F) , ascii codes are shown in the text editor like the image above. How do you stop this from happening ?

[jacobslusser]

It depends a bit on what you're trying to do. If you're interested in assigning the key combination CTRL+F a different behavior within ScintillaNET you'll want to use Scintilla's key bindings. You can read more about key bindings in the wiki.

If you want CTRL+F to launch a dialog like a search window, then you need to intercept that outside/before it gets passed to ScintillaNET. In most applications that is usually done by assigning the CTRL+F shortcut to a menu item in your main MenuStrip.

[seraphx2]

I think he is referring to the issue resolved by this code:

// Workaround for missing Scintilla.SupressControlCharacters
private void ctlScintilla_KeyPress(object sender, KeyPressEventArgs e)
{
    if (e.KeyChar < 32)
    {
        // Prevent control characters from getting inserted into the text buffer
        e.Handled = true;
        return;
    }
}

#135 | #121

[seraphx2]

It seems weird to allow this to be the default behavior. Very rarely do people want CTRL+* presses to render while trying to type code just because the CTRL combo wasn't caught before getting to Scintilla. Maybe ScintillaNET should have an option to turn this on and off? Maybe, something like scintilla.SuppressControlCharacters.

[jacobslusser]

Really?!? You wouldn't want Scintilla to handle CTRL+C, CTRL+V, CTRL+Z, CTRL+Y, etc...?

There are numerous CTRL+ keystrokes handled by Scintilla by default: https://sourceforge.net/p/scintilla/code/ci/default/tree/src/KeyMap.cxx

My feeling is that if you want to support CTRL+F, then it's set up perfectly for doing that. You have the option of intercepting it at the application level, binding it to a Scintilla command, or as a last resort handling it within Scintilla, but not by Scintilla by overriding KeyPress (or other events). For me that last use case is the exception to the rule, not the norm.

[seraphx2]

Sorry, I think the confusion of my idea comes from when I said: "wasn't caught before getting to Scintilla". What I was really meaning was that it wasn't handled before it got to the visible editor portion. It appears that special functionality assigned to preset combinations get triggered first. If there isn't one, scintilla allows that combination to continue to the editor where it gets printed as a character. By handling those combinations, that do get passed on, in the keypress event you can stop them from ever being printed visually.

The code above does not keep Scintilla from handling the preset CTRL+* keys (like the examples you gave). I just did CTRL-L and the line was still cut. What it does stop is combinations, that do not have special functionality assigned to them, from going all the way to the control as a visible character.

Maybe a better name would be needed for the property, but most people don't expect to see CTRL+G visibly show up in their text and I feel the code above should be on by default unless the user wants to see CTRL combo characters in the editor. Load up any code IDE and that probably doesn't happen by default (it does in ScintillaNET) in the majority of highlighters (unless maybe the language supports it for some reason?), so most people won't expect that behavior by default.

[jacobslusser]

Fair point.