> To subscribers of the xforms list from "T.C. Zhao"
<zhao@bloch.phys.uwm.edu> :
>
> Thanks for the test code. What you've suspected is true, that is,
> when a canvas goes away, the colormap associated with it is freed.
> ... Another
> solution, as you suggested, is to leave the colormap alone.
> This certainly avoids the X error and does not break existing code,
> but as spl pointed out, this may leak colormaps, a big no-no. The only
> workable solution that I can think of is add another
> routine so the user can indicate what the canvas should do with the
> colormap, perhaps something like set_canvas_keep_colormap or
> something like that.
>
How about adding two routines:
fl_share_canvas_colormap(), which be just like fl_set_canvas_colormap(),
but would set a flag to tell the canvas not to delete the colormap
when the canvas is freed, and
fl_free_colormap(), which would just free a colormap created with
fl_create_colormap().
Then existing programs using fl_set_canvas_colormap() would still work,
but someone who wanted to use one colormap in multiple canvases could
use the new routines. They'd just have to be careful not to mix calls to
fl_set_canvas_colormap() and fl_share_canvas_colormap().
-- Steve
-- -- EMail: stephen.langer@nist.gov Phone: (301) 975-5423 -- -- WWW: http://math.nist.gov/mcsd/Staff/SLanger/ Fax: (301) 990-4127 -- -- Mail: Building 820 Room 365; NIST; Gaithersburg, Md 20899-0001 -- _________________________________________________ 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/