Gadget undo/redo commands

BlitzMax Forums/MaxGUI Module/Gadget undo/redo commands

JoshK(Posted 2009) [#1]
I suggest adding the following methods and functions for both gadgets and proxy gadgets:

Method Undo()
Method Redo()
Method UndoAvail()
Method RedoAvail()

Function GadgetUndo()
Function GadgetRedo()
Function GadgetUndoAvail()
Function GadgetRedoAvail()

They don't need to actually do anything. They only need to exist in the base TGadget class. The reason for this is so that all the advanced text editor implementations can use one uniform command syntax, so you can easily switch between my codearea gadget, or the scintilla text gadget.

Adding this functionality will help encourage development of a truly working code editor gadget.


Brucey(Posted 2009) [#2]
Yes, I can see how it would be useful for a Push Button to have an Undo() method.

"Oops... I didn't mean to click that."


I don't think TGadget is a good place for this.


JoshK(Posted 2009) [#3]
This way any extended text editor gadget can use an extended undo/redo method, so that it is easy to switch between different implementations. Obviously text editors would be the only gadget that used it, much like the GadgetCopy() and Paste() commands.


SebHoll(Posted 2009) [#4]
The GadgetCut(), GadgetCopy() and GadgetPaste() use the flexible and non-commital Activate() methods with the ACTIVATE_CUT, ACTIVATE_COPY and ACTIVATE_PASTE constants respectively.

Is there any way you could leverage these, Leadwerks?


JoshK(Posted 2009) [#5]
If you don't add the functions in the module, no one else will use them, which defeats the purpose. Getting a working code editor gadget with syntax highlighting and undo/redo is a major concern to me. There are at least two implementations right now, neither of which work without bugs.


Mark Tiffany(Posted 2009) [#6]
Based on Seb's post, the request becomes the addition of ACTIVATE_UNDO, ACTIVATE_REDO and GadgetUndo, GadgetRedo.

Cut, Paste and Copy don't apply to buttons either, so extending this model would seem the most appropriate way to go.


SebHoll(Posted 2009) [#7]
the request becomes the addition of ACTIVATE_UNDO, ACTIVATE_REDO and GadgetUndo, GadgetRedo

Would people be happy with this? Concerning the GadgetUndo() and GadgetRedo() commands - my only concern is that these functions wouldn't currently have any use with any gadget in MaxGUI out of the box, and I suspect beginners might expect it to work with text-areas/text-fields accordingly.

I'm tempted to say we should compromise by simply adding the constants in the next release so that proxy-gadgets have a proposed standard mechanism to use internally, and the explicit commands can be added when more thought can be given to the behaviour of such commands with the native gadgets.


Mark Tiffany(Posted 2009) [#8]
I guess you could add the Undo / Redo methods to TGadget for now as well, albeit not implemented. Only more advanced users will find them, and hopefully will undestand that they are not yet implemented. Once someone writes them, then you can add GadgetUndo & GadgetRedo.


SebHoll(Posted 2009) [#9]
For GadgetUndoAvail() and GadgetRedoAvail(), I suppose we could extend the common-usage of the Query() interface by perhaps adding QUERY_UNDOAVAIL and QUERY_REDOAVAIL constants?

Not sure what Skid thinks of this? Maybe Query() should remain specifically for retrieving system handles.


JoshK(Posted 2009) [#10]
I'm tempted to say we should compromise by simply adding the constants in the next release so that proxy-gadgets have a proposed standard mechanism to use internally, and the explicit commands can be added when more thought can be given to the behaviour of such commands with the native gadgets.

That would be perfectly agreeable to me.