I've run into NRE's semi-randomly when using GTK#, which I think is due to Garbage collection of things that have been added to an object. Ex: I create a pixbuf, run some transforms, disposing all temporaries leaving behind a non-disposed Pixbuf. I use that generated Pixbuf in a TreeStore for a TreeView. If I force the app to redraw many times/cause a GC by dragging windows on top of it or moving the window itself, a NRE gets thrown from within the gtk_main loop. I've found that calling .Ref() on the Pixbuf will save it, and so will adding that pixbuf to an arraylist to preserve a reference to it. * This is a HORRIBLE kludge and I'm not even sure if it fixes it permanently (it stops the NRE in the short-run).
It would be good if this were fixed and/or proper documentation on
how to properly work around the issue.
I would think that the TreeStore would be smart enough to increment
the reference count when the Pixbuf is added to the list. I'm
thinkin' that's a potential underlying issue that's causing many
problems.
Also... when I create a window via Window w = new Window() {well.. a
sub-class that handles preloading data, no other instance data}.
Would the destruction of the Window instance via the GC cause any
issues? It would greatly make UI developing a pain when there is
instance data, like using Glade# and AutoConnect-ing instances.
So... basically... I want some sort of Guide for dealing with the GC
environment and GTK#... or a super-fix that will keep objects around
if they are referenced somehow in unmanaged code. (Now that I think
of it, replacing IntPtr with Handle fixes that.... I think.. not
sure, I'll see how that works). [I think it works by holding a
reference to the parent object... but... isn't the GC suppose to
handle circular references and clean up stuff like this?]
--
Thomas Harning Jr.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
