there are two solutions to the never-ending fl_do_forms loop: create a fa=
ke
object with no dimensions ( 0, 0, 0, 0 ) and do not set a callback for th=
at
object. this will get around the callback problem.=20
the second (and probably better) solution is to use exceptions. for insta=
nce,
when the user hits a quit button, the button's callback can throw an=20
exception object. that object will cascade up through the fl_do_forms loo=
p,
effectively escaping from it. this will, however, skip any cleanup in
the forms library.=20
the third option is to just let the program exit. when the program exits,=
all
unfreed memory will be automatically be freed when the OS deallocates the=
heap.
this is actually a more efficient process, IMO, than individually freeing
objects on the heap because all objects are being freed in one fell swoop.
of course, if you have some things that just *have* to be dealt with in t=
he
destructors, then this is not a solution (but then again, you might want =
to
re-examine your design anyways).
--=20
=A4--------------------------------------------------------------------=A4
| Aaron Gaudio mailto:icy_manipulator@mindless.com |
| http://www.rit.edu/~adg1653/ |
=A4--------------------------------------------------------------------=A4
| "The fool finds ignorance all around him. |
| The wise man finds ignorance within." |
=A4--------------------------------------------------------------------=A4
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuf2.usuhs.mil or see
http://bob.usuf2.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://bragg.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/