Created attachment 373157 [details] Screenshot of Erroneous Register Balance While editing a split transaction in one register, I changed a deposit from $142.89 to $571.53, pressed Enter to move to the next split, and then switched to the related register which was already open. On the related register, the Deposit column had updated but not the Balance column. Repeatedly switching between the registers did not fix the problem. When I went back to the split that I had edited and then moved focus to the next transaction to close the split view, this did fix the problem with the related register. So there appears to be a bug involving dirty edits where some values are saved and some are not prior to moving focus away from the edited transaction.
If I understand it correctly, it wont be updated as moving from one split to another in the same transaction will not update the same split in another register, it is only when the original transaction is committed that any related open register is updated, so I do not think this is a bug.
I think he's saying that the split edit *is* reflected in the other register, so that's the bug.
Correct. I was unsure the expected behavior. Is it supposed to not update open registers? Is it supposed to prompt me to save, which it would do if I closed the tab rather than switch tabs?
Edits should be invisible to the rest of the program until the transaction is committed, so viewing the transaction in another register should show the original value. This might be a problem with the way the transaction roll back is done: We make a copy of the transaction and modify the primary, meaning that any other register that has a reference to the splits sees the edits as they occur. If the edit is cancelled then the primary is replaced with the copy. There are extensive comments about all of this at the top of Transaction.c.
Had another look at this, took me a while to reproduce your problem. Like you said, if you edit a transaction in split view and pressed enter or carriage return and go to the corresponding open register the value is updated, don't you get an Imbalance split created and also the use of enter here is to commit/finish the transaction edit and so it will be reflected in the corresponding register. If you change a value and use the tab or mouse the corresponding register is not updated until you press enter or navigate to another transaction. So unless I am still misunderstanding, still think it is not a bug unless there is a difference between my Linux VM and Windows. Might try and boot my Windows machine tomorrow.
John was saying this shouldn't happen at all, and I tend to agree. It might make sense to have 2 or 3 copies of the transaction rather than the simple roll back strategy. This would help move in the direction of a proper Undo facility.
I don't have any trouble replicating the problem. I think Robert mis-typed (it's like mis-spoke but with a keyboard ;-)) when he said he'd pressed enter to move on to the next split. If I tab out of the split (so I don't commit the transaction) then the "other" register displays the transaction with no change to the balance. Pressing enter does commit the transaction and updates the balances in both registers as it should. I'm inclined to think that changing this will be a significant design change that would preclude it from being acceptable in a stable branch. For the split to be invisible to the account that "contains" it the split must not be in the global split hash... but then by extension the split for the register in which the edit is taking place also shouldn't be in the split hash, but I think that will complicate showing the transaction being edited.
