Dirty entity identification.

[David Hampton]

On Fri, 2005-07-22 at 14:09 -0400, Derek Atkins wrote:
> David Hampton <hampton-gnucash at rainbolthampton.net> writes:
> 
> > Absolutely 100% wrong.  Its called "Exit Without Saving."  I need a
> > method to tell the backend to drop everything on the floor.  Either that
> > or I need a global variable to pass data from point A in file 1, back
> > through the gtk idle loop to point B in file 2 to tell point B not to
> > bother checking to see if the data is dirty and should be saved before
> > quitting the program.
> 
> Shouldn't "qof_session_destroy()" do that for you?  Do you need to
> mark it clean because of some architectural issue or just because
> that's the way it's implemented at the moment?

I'm catching the delete_event triggered by clicking on the window
manager close button.  There will only be one content window open, but
it could have multiple views into the data (say the account tree, two
registers, and an invoice) and there could be any number of dialogs open
showing other aspects of the data in the book.  I didn't want to call
qof_session_destroy() at this point because any one of these could have
references into the book data, and there's a lot of unwinding and
cleaning up to do.  Frankly I don't know how well much of the code would
handle having the book yanked out from under it.  Sure, it should handle
that, but how much has been tested?  Its a can of worms I didn't want to
open.  The safest path in terms of code stability seemed to me to mark
the book clean and call the pre-existing shutdown function.  I know that
function works properly today.  I don't know if it would work after
destroying the book.  The shutdown code path expects to destroy the book
at some point during its execution, so code before that point may assume
the existence of the book and not test to see if its really there.

David