about bug #107953 -- need to queue a report refresh?

[Derek Atkins]

I finally tracked down bug 107953 (you can see my report in bugzilla
at http://bugzilla.gnome.org/show_bug.cgi?id=107953).  The problem
report was that the user brought up the options dialog for a report,
clicked Apply, and then clicked OK and GnuCash would crash.

Basically, the apply button callback calls a refresh of a report,
which calls gnc_mdi_show_progress(), which calls gtk_main_iteration(),
which accepts another button press in the options dialog.  If the user
hits OK at this point (or cancel, I suspect) it will wind up
re-applying the changes, and then closing the dialog.  Then, when the
stack pops back to the original apply function the dialog (and its
anciallary data) is no longer there -- Boom!

The temporary workaround I implemented just stops the symptom -- the
user can't hit "ok" (or anything else) until the apply completes.  But
I think there is an underlying problem with how the option dialog
interfaces with the reports refresh mechanism.  I don't understand MDI
well enough to know the RIGHT fix...  I suspect we need a lock around
the refresh and probably some way to delay (or queue) the actual
refresh until after we return from the apply().

I've closed the bug (because the symptom is fixed), but I've sent this
email here because I'm hoping someone else might have an idea for how
to fix the real, underlying problem.   Any takers?

-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
       warlord at MIT.EDU                        PGP key available