Seems like when I undo after applying a stamp it doesn’t actually undo that action.
My workaround was to save and then revert, but Tinderbox quits unexpectedly. Quits quite frequently actually.
Tried opening a document without the stamp applied, applied it, and then undid 'til I heard the bell. Stamp update’s still applied.
I think most (?) actions bypass the undo, from which I infer that undo is trying to catch ‘manual’ UI edits.
I don’t think there’s a canonical listing of what does/doesn’t go on the undo stack.
Similar to the good ol’ days of continuously Command-S-ing.
Not having a reliable undo/redo’s a pretty big issue: basically means having to remember to save before every action to revert, ie, undo. Sounds virtually unmanageable, unless I’m missing another workaround?
Unexpectedly quit again 
Not all! I rarely if ever Cmd+S (except when beta testing new features and therefore might be trying things that I know might fail.) For general work on public releases Tinderbox is rock solid. Of course if you find a crash scenario, a crash may occur and will occur in that context, repeatably—until it is fixed by a new release. The latter is true of all software.
If the doc is unstable or crashes and I can’t recall what I changed most recently, I’d use Time Machine to roll back to before you worked on the bad code. Failing that zip up a copy (or give a public link to it if big) in an email to Tinderbox support: tinderbox@eastgate.com.
For us fellow users here in the forum, we need to have some idea what you were doing. Agent based, or a rule/edict. Do you have code you can post here.
As to blaming undo, you’ll find the same with many macro systems: AppleScript, MSOffice, etc. where some outcomes get in the undo queue and others don’t. I’m not sure the developer can necessarily catch all things.
Applying stamps is not undoable.
In the general case, this would require truly exorbitant use of memory — essentially duplicating the entire Tinderbox document at least once whenever a stamp is applied. Remember: a stamp is an action, and actions can do anything.. I assume you’re familiar with Turing-completeness and Gödel’s incompleteness theorem?
You can, of course, use Save As… to save copies. Time Machine is your friend.
Fair point 
Difficult to implement, but it’s doable, eg, PostgreSQL rollbacks.
If engineers want to tackle these challenges, I’d assume the community would welcome them, unless there’s something more pressing…which leads me to…
Re rock solid, that’s not been my experience. Tinderbox is probably the least stable app running on my machine. It actually crashed while running in the background today.
I’m really enjoying discovering TB, but the frequent crashes are disruptive, especially when I’m in a high flow state. Factoring in the interruptions while not even using, this issue unquestionably creates the most friction.
Broadening the scope of undo/redo would be nice to have. But, if I could ask for anything, it would be rock solid stability.
I’ve not discerned a pattern so far, but I’m submitting crash reports via MacOS. Hopefully they’re being looked at.
PS I was excited about TB and was only enthusiastic to contribute. Reading the responses below, it seems some of this post has been misread and it’s been generally misinterpreted. I’m now a new customer with a software product that crashes regularly and, apparently, no support. Might be wasting my time, but I’ll keep submitting crash reports through MacOS and my fingers crossed. If there’s anything else I can do to help diagnose, please let me know.
Hm. Sample of one. By comparison, I find the app very stable and I work in it every day and with larger more complex docs than most. So, by inference I should get crashes. I don’t. So please, for the sake of other readers here be mindful about sample size when throwing shade about the app’s stability. I do accept your experience is doubtless as described but it is certainly not normal and most likely due you some of your eccentric action code, even if unintentionally so.
You have also kindly provided some code examples, in other threads, that follow no Tinderbox documentation examples I can find. Thus likely garbage in, garbage out. When using scripting/macros in apps, they are far more prone to user input error given the range of lower level functions. As an app, Tinderbox is not unstable; some users’ use of it may cause it to be ome so, but not in a way I think reflects on the build quality of the app.
We all don’t know what we don’t know, but typing on “what makes sense to me, based on experience in other places” may not always help.
This is a user to user forum and there are plenty here who will try and help. But just complaining doesn’t give anyone any tractable info with which to help you.
I’ve used Tinderbox since 2004 (it dates from c.2001, though has been re-written completely at least once since then), so I’ve had ample opportunity to see if the app is as unstable as you imply. Indeed, there are others here who’ve used the app longer than I have. I think people would have noticed if it were as bad as you suggest.
If you’d like help, the community here will try, but please give some tractable info to work with. Otherwise I’ll lock off† these threads as they help no one.
†. As mod/admin here. It’s a hat I’m rarely called upon to don as this is a generally good-natured forum and I hate wasting time that could be helping people on dealing with unreproducible problems.
I just told you why this is technically infeasible.
You’ve not submitted a single crash report to us.
Under these conditions, I’m not likely to read further.
A technical explanation for the bystanders.
“NomasPrime” suggests that transactional rollback for every operation isn’t that hard, and posits PostgreSQL rollbacks as an example. This is perfectly true, and as shown elsewhere in this discussion, “NomasPrime” has some technical knowledge.
Some systems absolutely require transactional integrity. That is, if an operation fails, it leaves the system unchanged, and if it succeeds, every part of the transaction is performed. For example, if you tell your bank "transfer $100 from savings to checking”, one of two things is absolutely guaranteed to happen.
This guarantee matters a lot to the bank, which may need to process thousands or millions of transactions a day. On that scale, all sorts of bizarre things might happen. Power failures. Cosmic rays. Wild and crazy stuff that happens one time in a million — that’s going to happen every day.
The problem is that, even for very simple tasks like adding and subtracting numbers from account balances, transactional processing is difficult and (in consequence) slow. Every introduction to transactional processing I’ve seen begins with a warning: you don’t want to do this if you don’t absolutely need it.
Now, you folks all know intuitively about the cost of the transactional guarantee. Every time you use an ATM, there’s a huge delay while it hits the database. Every time you order an airline ticket, there’s a huge delay while it hits SABRE for the ticket and the bank for your payment. (I assume that the ordering site has a third transactional system that holds they pending payment and the pending ticket, so that if one transaction fails it can reverse the other, because otherwise Orbitz would wind up holding a portfolio of airplane tickets for which payment failed, and a pile of cash it received for plane tickets that someone else snapped up a moment before. Interesting problem!)
Anyway, you can live with that because (a) you can’t live without the bank and if the bank says, “wait”, what can you do? and (b) you already went to the ATM, so what’s another few seconds? You can’t live with that every time you click a mouse. No one can.
Sure, we could do more of this by doing less. Map view? Immense complexity, in support of things like those nice curved links with editable splines, editable anchors, editable and repositionable labels. Make that a thousand times slower: you can’t do anything.
So, that’s what this discussion was about. I don’t want to assume bad faith here, because there might be some language issues, and misunderstanding is always possible. But this is not helping anything.