Disable some menu shortcuts when using scintilla

[GWRon]

When using scintilla as textare this means it provides some shortcuts already. MaxIDE overrides some of these shortcuts for randomly or seldom used features.

Eg "ctrl + d" duplicates a line in scintilla. The "build modules" command uses this shortcut while not being of an everyday use.

Also menu entries like "block indent" would no longer be necessary: select the lines of desire, hit "tab" and it auto-block-indents for you. (with "UNDO" undoing this indentation for each line separately - a bug if you want to name it that way).

So some stuff (block indent) needs to either show (but not react) "Tab" and "Shift + Tab" for scintilla using builds.
Also using "TAB" with a multi-line select now leads to TWO tabs being inserted (the indent-block-menu-entry only adds one).
Line ~5322 (If id=EVENT_KEYCHAR And this And key=KEY_TAB...)

[GWRon]

A simple fix would be a global variable (global scintillaEditorEnabled;int = True). Or to introduce a new Method (like the TextAreaHasCharEventSupressionFixup()) which expresses if the textarea can handle block indentation on itself.

What can be done too? Writing a Block(Un)Indent() method which does indent all lines in the maxgui textarea, and nothing in the scintilla textarea (as its automatically done). That way other textareas done in MaxGUI automatically inherit this feature.

Adding that fix described in the first paragraph automatically fixes the UNDO issue with this block-indendation.

[GWRon]

Maybe we could add an identifier to the textareas? So we could distinguish between "maxgui" and "scintilla" without relying on BRL.reflection - while this would be a suitable solution too.

Having CTRL+D is crucial when creating constants or multiple IFs.

[woollybah]

Yes, a method is preferable, rather than polluting code with globals.
I'm not sure why you think the menu would no longer be necessary though. Not everyone knows every keyboard shortcut.

[woollybah]

I don't think anything is "crucial" :-p

I've added indent and undo action support.

[GWRon]

I am not saying that the menu is no longer needed ... for modules building. Block indentation could be removed the same way as "space" does not have a custom entry. Tab spacing and indentation should be known to everyone ever having had opened a text editor. It is a common action. Some prefer to indent by space... for them the menu entry might be valid (but then of course "tab" wont be correct except for auto-tab2space). Am 7. Mai 2019 17:16:08 MESZ schrieb Brucey <[email protected]>:

…

Yes, a method is preferable, rather than polluting code with globals. I'm not sure why you think the menu would no longer be necessary though. Not everyone knows every keyboard shortcut. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #41 (comment)

[GWRon]

Undo action support is to undo a multiline indentation in one step?

What concerns me a bit that every TGadget has this stub functions now. Couldn't this be done differently? Extending TGadget, behaviour-component-system with Getters and Runners (we only use "HasX()" and "DoY()" for now.

Or do you think it is neglectable for our purposes and can be kept as simple as possible?

[GWRon]

Maybe we could add an identifier to the textareas? So we could distinguish between "maxgui" and "scintilla" without relying on BRL.reflection - while this would be a suitable solution too.

What do you think: how should MaxIDE (and other code) generally identify a specific implementation of eg. a TextArea widget?

• generic "GetClassName:string()" (non-reflection)
• using reflection code
• circumvent any of them and provide a dozen of "HasFunctionalityXYZ()" methods (here: "HasBlockIndent()")

[woollybah]

What concerns me a bit that every TGadget has this stub functions now. Couldn't this be done differently?
That's how MaxGUI is designed - one really long list of procedural awesomeness.

The whole idea behind having different textareas is that you can basically drop them in and not need to know which particular one it is. I don't see much need to have a textarea know which particular implementation it is. I doubt there'll be any others anyway.

[GWRon]

Not the textarea should know about it ... but MaxIDE should be able to distinguish the implementations.

As said some menu entries eat the "commonly known" scintilla shortcuts (you know them if you use other scintilla-using editors). We could generally remove some shortcuts regardless of what textarea is used - but I wanted to remove as "fine grained" as possible.

Once you got used to "ctrl + D" to duplicate a line you will miss it when it tries to rebuild modules instead.

[GWRon]

I still vote for remvoving the shortcut "ctrl+D" to build modules ... it is so rarely used that these people could use the menu entry without utilizing the shortcut.