On Sun, 14 Sep 2003 19:37:02 +0200, Christer Palm <palm nogui se> claimed: > Aaron Isotton wrote: > > > > - The GtkTreeIter structure is okay for C programs, but in my case I > > have a custom iterator class which can not be converted to three > > void* pointers in a nice way. What I'd like to do is to allocate a > > iterator for every GtkTreeIter and put a pointer to it into > > user_data. The problem is that I don't know when to free the > > allocated object, to avoid memory leaks. Any ideas? > > > > This, in fact, _is_ documented :-) > > From the TreeModel docs: > > The lifecycle of an iterator can be a little confusing at first. > Iterators are expected to always be valid for as long as the model is > unchanged (and doesn't emit a signal). The model is considered to own > all outstanding iterators and nothing needs to be done to free them > from the user's point of view. As far as I can see, this means that a GtkTreeIter will be valid until the model is unchanged and doesn't emit a signal; the problem is that everytime get_iter_vfunc is called I have to allocate a new iterator and put a pointer to it into user_data because my iterators cannot be easily converted to three void pointers; but when do I free the data allocated there? Or do I _have_ to use only the three pointers and no additional data? Another way would be to put something like an int inside the user_data pointer, and to maintain a lookup table mapping between these ints and the real iterators, and to clear it everytime something changes. But this would be *so* ugly. [snip] > Beware though - this is in theory. I tried to do something similar to > what you are doing, and frankly, I had to give up. The TreeView is not > > particularly happy with the model changing outside its control. I've > seen all sorts of behaviour, including using invalidated (as per the > documentation) iterators, and various internal asserts complaining > about > that the model has changed, even though these changes have been > properly communicated to the view. Ah. Nice to know. Thanks a lot. - Aaron Isotton -- http://www.isotton.com/
Attachment:
pgpsOXMI9s87n.pgp
Description: PGP signature