> I have encountered a memory leak when using statically initialised
> menus (ie when using fl_set_menu_entries() and an array of FL_PUP_ENTRY
> structures) which I think is an internal library bug. I have an app
> which creates many temporary forms using such code. Each form is
> subsequently killed off with a sequence
> fl_hide_form(ob->form);
> fl_free_form(ob->form);
> free(ob->form->fdui);
This is a nit but this is probably bad practice since fl_free_form(),
by necessity, does a free() of the form's data structures. Thus, in
the subsequent free() of `fdui', you are dereferencing a no longer
valid pointer. I'd flip the order:
free(ob->form->fdui);
fl_hide_form(ob->form);
fl_free_form(ob->form);
Not that this solves your popup problem, of course.
I think the problem is assuming that fl_free_form() destroys the
popup as well. Popups, being basically independent Windows sort of
stand to the side of the form on which they're created. The form
doesn't really know anything about what Popups exist, as far as I can
tell. I believe you're going to have to do this bookkeeping yourself
and use fl_freepup() to blow away the popup resources.
I suppose that XForms could easily keep track of what Popup belongs to
what Window and scan the list of Popups whenever fl_free_form() is
executed.
My solution has always been to dynamically create and destroy Popups
as they are invoked and released, respectively, since I tend to need
to make changes to the Popup on the fly anyhow, but I can understand
that this may not be an appropriate solution for all users.
spl
_________________________________________________
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://bloch.phys.uwm.edu/xforms
List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/