Oops! Or, The Limited Utility of Undo

[dmrogers (Dave Rogers)]

For the most part, the Tinderbox UI is about as accessible as a complex program can be. But occasionally, accidents may happen.

In an automated document, where a container may assign particular attributes by means of an OnAdd action, an accidental dislocation of a child note poses some challenges.

Simply dragging the note back to it’s proper place in the hierarchy will invoke the OnAdd action, and alter many of the attributes, which may not be desirable.

There is little in the way of information regarding the capabilities and limitations of Undo in ATbRef.

Personal experience suggests it can’t “undo” the effects of an unintended change in hierarchy with respect to OnAdd.

I mostly rely on the trackpad. My recent embrace of Tabs finds my fingers fiddling around near the top of the window where the tabs are, which is also near my most recent posts.

Today I accidentally made a sibling into a child of another sibling, and simply dragging it back to its correct location invoked OnAdd, which made an unwanted change to a number of attributes. And Undo didn’t seem to fix anything.

One might wish that it would be a simple matter of selecting Revert To from the File menu. But again, personal experience shows that the “revert” feature built into MacOS, or as implemented in Tinderbox, is problematic at best.

One can recover a previous version, but the user experience, at least this user’s experience suggests, there is something not right with the way the facility works.

Perhaps at an upcoming meetup we can do something of a deep dive into how these features are supposed to work. Perhaps it’s something wrong with my file system, or the way I’m going about it.

In a related question, is there a way to make an attribute “read only” once it has been created, such that an accidental, or mistaken movement into or out of a container restrains the OnAdd action?

For now, I’ll try to be more careful as I “mouse around” on the trackpad near the outline.

[mwra (Mark Anderson)]

@dmrogers

There is little in the way of information regarding the capabilities and limitations of Undo in ATbRef.

But only because the feature is not documented in any depth!

Something we do in the app may have a host of (unseen) changes which we easily overlook. When undoing the fine detail is exposed, especially if not every change is saved in the undo stack.

$OnAdd, by intent, fires once when a note is added. If a child note is removed and re-added, the container just sees an ‘add’ event and fire OnAdd. How would it know any differently.

If you foresee (accidental) removal and re-addition of children, add a boolean attribute to record if the note has been added once already. Then wrap the r$OnAdd code in an if() test to check if the boolean is set in the added note. If it is, the necessary code has already run and we do nothing, no further changes happen. If not, the code is run and the Boolean is set (in the added note), preventing a match if the OnAdd even is triggered again.

Ideally, UI missteps such as described shouldn’t occur so there is no formal need for the above structure in OnAdd. But having discovered this problem in your personal usage, a guard boolean is easy to implement. As there will be existing ‘added’ notes, it is not too big a deal to select/quickstamp those to set the Boolean so as to back-fill the mis-move guard code.

Also see: logical OR assignment.

HTH

[eastgate]

In my opinion, Undo ought NOT to exempt the moved note from being subject to the OnAdd action of the container to which it is returning. However, at present Tinderbox does NOT reapply the OnAdd action during Undo. So, that’s good for you

Revert in Tinderbox is quite difficult because Tinderbox always has so much going on. It’s quite tricky to stop everything, swap in the reverted data, and start things up again. If you have a document that crashes on revert, let me know and perhaps I can fix it for everyone.

Time Machine is, in my experience, actually quite good for recovery.

The best way to make an attribute “ReadOnly” is to create a second attribute. You might have Price and **Price!". Copy the value of $Price to $Price! when you know it’s valid. Thereafter, you can use a Rule to consorting $Price to $Price!. Or, you can use an agent to warn you that the $Price is wrong.

[satikusala (Michael Becker)]

@dmrogers

Today I accidentally made a sibling into a child of another sibling, and simply dragging it back to its correct location invoked OnAdd, which made an unwanted change to a number of attributes. And Undo didn’t seem to fix anything.

Hi Dave. I don’t know all the details of your situation, but I have discussed this on several occasions during meetups. If there is already a value in a prototype and you don’t want an $OnAdd to to take effect then you simply add a | the on $OnAdd, e.g., $Prototype|="pPage"'. In this situation, the prototype would not be changed when dragging it back into the $Container. I’ve noted and tested this with other attributes, but I suspect it would work the same.

[mwra (Mark Anderson)]

Closing the loop, the |= operator is the ‘logical OR’ I linked to above.

[dmrogers (Dave Rogers)]

As always, I am not very methodical in how I approach a novel situation. Having created the error by means of the graphical user interface, I immediately, and without thinking, sought to correct it in the same way, i.e. dragging the note back to its proper place, and thus invoking OnAdd.

Noticing the change in the attributes, I then appealed to Undo. I don’t recall exactly what the option was that it offered, but I believe it offered only to undo “select.” It didn’t undo the attribute change.

Ultimately, I manually entered the original values, as recorded in the exported html file. (“Like an animal.” )

Perhaps “read only” was not the best way to suggest how to prevent unintentional attribute changes, but it’s what came to mind most readily.

I will add the appropriate boolean checks as Mark A. described above.

As regards revert, in my experience, the marmot always causes Tinderbox to crash when attempting to revert. (I suppose I’ll regret writing that.) I dutifully send the crash reports, albeit likely without explanatory narrative, as I’m usually in a hurry just to get my document up and open again.

And going from my fallible memory, Revert also seems to change the file name, removing the .tbx file suffix. I usually notice this when a script fails because the document doesn’t contain the suffix it expects to see. I don’t know if that’s an aspect of Time Machine and how it manages snapshots, or something else. It has happened often enough that I now know to check and add the .tbx suffix.

In one extreme instance, I was saved by Backblaze, as no version I could find in Time Machine matched what I had already published. So, “belt and suspenders” and all that.

As we automate, we add complexity for the sake of efficiency(?), and some of these complex interactions yield unanticipated outcomes. Guarding against those adds another layer of automation and complexity.

I’m not complaining, I’m just making the observation. This is the application I’ve chosen, and it’s up to me to make it work. But it can give one pause to reflect sometimes.

All is well. “I’ll be more careful next time,” and so on.

Thanks for the tip about the guard boolean. I’m glad that Tinderbox also affords this responsive and helpful community. “We’re all in this together.”