Quicken for Windows needs an Undo feature

Rocket J Squirrel

@Rocket J Squirrel

Undo simply can't be bolted on to an application after the fact. Every operation that affects the data has to push its effect onto an undo stack. This means that a large number of QWin functions would need augmentation to handle this. Forget it, it is just not doable short of a full rewrite.

@Chris_QPW

I agree, the database not supporting rollbacks is just the tip of the iceberg.

@Phil Burton

So what does the rest of the iceberg look like.

Guys! I just figured out a way for Quicken to implement Undo without changing the database or rewriting all the code!

We know that whenever the user makes any change to the database - entering a transaction, changing a transaction, deleting a transaction, etc. - Quicken immediately writes the change to the data file.

So to allow Undo, all that needs to change in the code is for Quicken to write every change to a new temporary copy of the data file instead of always writing to the active file. Then any change can be easily undone by reverting to the previous copy. Every session will create as many files as the user makes changes.

You will need to invest in a ton of drive storage space, but so what? (Ooh, or that cloud thing, whatever that is.) At the end of a session, all the new temporary files created during the session can be deleted.

I am only 3/4 joking.

SeaStar

I heartily cast a YES vote to minimally include an "Undo last entry" option as well as a "Find last entry" option. If possible, please provide a feature to view several recent entries and enable User a way to select and update the problem entry. Thanks.

Chris_QPW

So to allow Undo, all that needs to change in the code is for Quicken to write every change to a new temporary copy of the data file instead of always writing to the active file. Then any change can be easily undone by reverting to the previous copy. Every session will create as many files as the user makes changes.

You will need to invest in a ton of drive storage space, but so what? (Ooh, or that cloud thing, whatever that is.) At the end of a session, all the new temporary files created during the session can be deleted.

I am only 3/4 joking.

Just so people know this is a joke. One of the aspects of the "iceberg" I mentioned can be shown by actually working through this above statement.

"Write every change to a new temporary copy of the data file".

Define "change". Example where this isn't what one might think.

The user selects 100 transactions, and then deletes them. To the user this is one change, but it certainly isn't at the database/data file level, which might even have several database calls to just delete one transaction. So, you can't go to the lowest level and say on every database command save copy of data file. Well, you could, but when you go to do the undo, you would have no idea of how far back in the history of data files to go. You need "some top down information". Now that means that for every "user change" you have to store something that tells you are starting/ending "the change". That can't be done in one low level spot, it will be all over the UI code.