I have a question about the register design. I've looked through the .h files are this doesn't seem to be addressed.
Background: The register has a whole bunch of different cells. For example there is a cell for a posting date, one for a check number, one for an account, and so on. Depending which type of row you are currently on, only some of these cells are contained in the current cursor. For example, in transaction journal mode if you are on a split row then the account cell is in the current cursor but the posting date is not (instead it is part of a separate cursor for the transaction row). At any time it is possible to look up the value of the posting date cell, but if you are currently sitting on a split row, then the posting date cell contains the posting date of the last transaction row visited, which *might* not have been the same transaction that your current split belongs to. Have I lost you yet? Because I'm wondering if this is the way it is supposed to be. There would seem to be two possibilities: 1. You are not supposed to assume that cells outside the current cursor are valid. So when you are on a split row, all cells that are not in the split cursor, such as transaction-level cells like the posting date, should not be trusted. 2. All cells are supposed to be up-to-date, even if they are not part of the current cursor. This would mean that when the user tries to move from a split row in transaction A to a split row in transaction B, you'd have to first visit (programmatically) the cursor of transaction B to make sure all the transaction-related cells are up-to-date, then move on to the split the user wanted. Does anyone know which is correct? Most of the code that looks up cell values seems to either observe #1 or works either way, but there is one spot involved in bug 567709 that definitely assumes #2. Cheers, Charles _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
