{"id":483,"date":"2020-09-08T23:08:08","date_gmt":"2020-09-08T23:08:08","guid":{"rendered":"http:\/\/www.scrootchme.com\/bmc\/?p=483"},"modified":"2025-07-10T17:17:34","modified_gmt":"2025-07-10T17:17:34","slug":"undo-onto-others","status":"publish","type":"post","link":"http:\/\/www.scrootchme.com\/bmc\/undo-onto-others\/","title":{"rendered":"UNDO onto others…"},"content":{"rendered":"\n

Last time<\/a> we covered the critical question of maintaining a scaled editing area so that we can work on a 16 bit resolution ILDA file on lower resolution screens. As I mentioned in that post, one of the other areas we want to address sooner rather than later is ‘undo’\/’redo’. All modern editors are expected to do this well and users have become accustomed to relying on the feature.<\/p>\n\n\n\n

Instead of starting from scratch, our good friend JUCE has an UndoManager class<\/a>. It is a specialized container class that holds instances of an UndoableAction class<\/a>. One of the things I like about this setup is you add UndoableAction instances to the manager by “performing” them. That is, the operation is ‘done’ initially by exactly the same code that will be executed for a ‘redo’ operation. This eliminates a common pitfall with undo\/redo systems bolted on after the fact, where do and redo are different bodies of code that don’t always stay in perfect sync.<\/p>\n\n\n\n

Up to now our FrameEditor worker class has basically had public get<\/em> and set<\/em> functions. For example, from FrameEditor.h:<\/p>\n\n\n\n

float getRefOpacity() { return refOpacity; }\nvoid setRefOpacity (float opacity);<\/code><\/pre>\n\n\n\n
Step one to implement our Undo\/Redo system is to make this into three functions, get, undoable set, and destructive set:<\/p>\n\n\n\n
float getRefOpacity() { return refOpacity; }\nvoid setRefOpacity (float opacity);\nvoid _setRefOpacity (float opacity);<\/code><\/pre>\n\n\n\n
The function _setRefOpacity is just our original setRefOpacity function renamed. This is our “destructive” version of the operation. Our new setRefOpacity function is the undoable version, the one regular clients call. Instead of calling _setRefOpacity directly, it creates an instance of this class and performs it with the UndoManager derived class:<\/p>\n\n\n\n
class UndoableSetRefAlpha : public UndoableAction\n{\npublic:\n    UndoableSetRefAlpha (FrameEditor* editor, float alpha)\n    : newAlpha (alpha), frameEditor (editor) {;}\n    \n    bool perform() override\n    {\n        oldAlpha = frameEditor->getRefOpacity();\n        frameEditor->_setRefOpacity (newAlpha);\n        return true;\n    }\n    \n    bool undo() override\n    {\n        frameEditor->_setRefOpacity (oldAlpha);\n        return true;\n    }\n    \nprivate:\n    float oldAlpha;\n    float newAlpha;\n    FrameEditor* frameEditor;\n};\n<\/code><\/pre>\n\n\n\n
When the class is instantiated it saves the desired new value and a pointer to our FrameEditor worker class. The perform() method saves the old (current) value and sets the new one, using the destructive _setRefOpacity. Undo uses the same function to set the old, preserved value.<\/p>\n\n\n\n
One concern with a scheme like this is the scope, or life, of objects. We have an instance of this undoable object class that points to our FrameEditor class. We want to make sure that we never get into a situation where we try to ‘undo’ something after our FrameEditor has already been deleted. I chose to elliminate this possibility by making our FrameEditor and the UndoManager the same object.  FrameEditor “inherits” from UndoManager:<\/p>\n\n\n\n
class FrameEditor  : public ActionBroadcaster,\n                     public UndoManager<\/code><\/pre>\n\n\n\n
In various object oriented programming paradigms, this is called the “Is-A” vs “Has-A” question. Or, “the entity relationship model”, if you want to sound even more obnoxious. To me it just made sense that our FrameEditor worker class, which we can now ask to perform undoable operations, is the same object we use to undo them.<\/p>\n\n\n\n
But, regardless, either having our FrameEditor be<\/em> an UndoManager or have<\/em> an UndoManager as a member variable solves our scope problem. The scope, or object life, of our worker class, the UndoManager, and any saved UndoableAction classes that point back to our worker class, are all tied together.<\/p>\n\n\n\n
With the Is-A approach, our undoable set function looks something like this:<\/p>\n\n\n\n
void FrameEditor::setRefOpacity (float opacity)\n{\n    if (opacity < 0)\n        opacity = 0;\n    else if (opacity > 1.0)\n        opacity = 1.0;\n    \n    if (opacity != refOpacity)\n\n        perform(new UndoableSetRefAlpha (this, opacity), \"Background Opacity\");\n}<\/code><\/pre>\n\n\n\n
We make sure the caller isn’t passing in an out-of-range value, check if the request actually changes anything, and, if yes, create and perform the UndoableAction class we defined for this operation (automatically saving it into the UndoManager maintained list).<\/p>\n\n\n\n
This works, but we run into one headache. If we grab the opacity slider and play with it, we get a zillion of these events stacked up to undo. Generally, that’s not what the user expects. They have a starting opacity, fiddled with the slider, then stopped. From their point of view, all that fiddling is just one undoable adjustment.<\/p>\n\n\n\n
The JUCE UndoManager has a mechanism called “Transactions”, meant to lump multiple UndoableActions into a single undo\/redo operation. But it also has a nice rollback feature, which helps us here:<\/p>\n\n\n\n
void FrameEditor::setRefOpacity (float opacity)\n{\n    if (opacity < 0)\n        opacity = 0;\n    else if (opacity > 1.0)\n        opacity = 1.0;\n    \n    if (opacity != refOpacity)\n    {\n        if (getCurrentTransactionName() == \"Background Opacity\")\n            undoCurrentTransactionOnly();\n        \n        beginNewTransaction (\"Background Opacity\");\n        perform(new UndoableSetRefAlpha (this, opacity));\n    }\n}<\/code><\/pre>\n\n\n\n
If we are doing a series of opacity changes, we keep rolling back the transaction to our original value, then adjust to the new one. This turns slider fiddling into a single undo\/redo step.<\/p>\n\n\n\n
At this point our background layer looks a lot like last time:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
I added a button to clear (delete) the background image and reference grid you can turn on and off, but the big difference is that we can now undo and redo all the adjustments you make:<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Now that we have a scheme for undo\/redo and a way to scale, draw, and interact with ILDA resolution data, it is time to open some!<\/p>\n\n\n\n
The ILDA image exchange format<\/a> is pretty bare bones. It doesn’t have a mechanism to include vendor specific information. So we will need a to support two formats for opening:<\/p>\n\n\n\n