'Have you ever had that sinking feeling when you realize—just a split second too late—that you shouldn’t have clicked “Okay” in the “Are you sure you want to quit?” dialog?
Yes? Well, you’re in good company—everybody has had a similar experience, so there’s no need to feel ashamed about it. It’s not your fault: it’s your software’s fault.'
Yes? Well, you’re in good company—everybody has had a similar experience, so there’s no need to feel ashamed about it. It’s not your fault: it’s your software’s fault.'
This reminds of when I first started adding undo support to VoodooPad. I didn't want to. I hated the very idea, because I just could not wrap my head around how it could possibly be done in a sane manner.
This was also before I actually read the Cocoa documentation on how to do undo. Turns out it's way easy to do (for most cases), assuming you keep it in mind when you are designing your code. Hurrah for Objective-C, messaging, and dynamic typing.
But of course, I had already moved on with my code to the point where retrofitting undo support in VoodooPad was a huge pain. And this is why VoodooPad has such crappy undo support. So here's my advice to anyone starting out on a new app:
Think about undo support from the very start. It's not hard, you just need to understand what's going on. Read the docs, make some tests that flex your code (don't forget to test redo as well!), and you and your customers will be happier for it.
(You should also think about AppleScript from the very start as well since it tends to reqire a certain architecture you might not be expecting. But AppleScript gives me nightmares, so I like to pretend people aren't asking for it.)
Via Daring Fireball.