The more I delve into this, the more I find. What's going on is that
the register winds up calling SplitLedger.c:LedgerTraverse(). It
winds up, at the bottom of the function, following the path of
GNC_VERIFY_NO. For some reason this never winds up calling
RollbackEdit(), as far as I can tell.
Anyways, the 'No' path winds up breaking out and returning 'FALSE',
which is the same thing that 'Yes' returns.
Control then returns to gnc_table_traverse_update(), which winds up
returning the value it just got above (FALSE), as the value
'abort_move'. Control then pops back to
gnucash_sheet_key_press_event() which checks whether abort_move() was
set (it wasn't in this case), so it falls through to
gnucash_sheet_cursor_move() which winds up calling
xaccTransCommitEdit() [indirectly].
So the question is: where is the bug? Should LedgerTraverse() return
TRUE instead of FALSE in this particular case? Also, why isn't
RollbackEdit() being called?
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
