Hi,
I've just checked in code that implements transaction rollback.
This makes the gui behave more nicely, as per Robb's suggestions.
There's an engine compnenent and a gui componenet to the commit/rollback
scheme. On the engine side, one must always call BeginEdit()
before starting to edit a transaction. When you think you're done,
you can call CommitEdit() to commit the changes, or RollbackEdit() to
go back to how things were before you started the edit. Think of it as
a one-shot mega-undo for that transaction.
Note that the query engine uses the original values, not the currently
edited values, when performing a sort. This allows your to e.g. edit
the date without having the transaction hop around in the gui while you
do it.
On the gui side, commits are now performed on a per-transaction basis,
rather than a per-split (per-journal-entry) basis. This means that
if you have a transaction with a lot of splits in it, you can edit them
all you want without having to commit one before moving to the next.
Similarly, the "cancel" button will now undo the changes to all of the
lines in the transaction display, not just to one line (one split) at a
time.
As usual, the code is only lightly tested; it didn't core dump out of
the gate. So enjoy ...
--linas
P.S. So what's the deal, do I have to offer cash incentives for bug
reports? Why's no one complaining? Is it not buggy? Or is it so bad
that no-ones using it?
Oh, never mind, I take that back. Just send patches. Skip the bug
reports.
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
