Re: [gtkmm] RE: TreeView Model, SEGV on append - more info

Am 2003.10.27 19:32 schrieb(en) "Ohrnberger, Erik":
	I have a little bit more information on this.

	In the class that uses the TreeView, I have the following

Class is subclassed from Gtk::ScrolledWindow, and contains the
data members:
	Gtk::TreeView					tvMoldList;
	MoldListCols*					pCols;
	Glib::RefPtr<Gtk::ListStore>			pMoldListModel;

In the class CTOR, I create the column instance (pCols) with a new.  I
create the model:
	pMoldListModel = ListStore::create( *pCols );

Set the model to the treeview:
	tvMoldList.set_model( pMoldListModel );

and then append the columns to the treeview:
	tvMoldList.append_column( "Icon", (*pCols).Icon );

In the MoldListCols CTOR, I add it's columns:
	add( Icon ); ....

In one of the class's methods, I want to add a single line to the
however, by then the data member pMoldListModel returns a NULL, like
lost scope or something.  Well, once I create another model, load all
items that should be in there and append line item that I wanted
it appears to work just fine.

The call
    pMoldListModel = ListStore::create( *pCols );
does indeed succeed and pMoldListModel is != 0 by then?

You do instantiate Gtk::Main before your ctor is executed?

There is no other call pMoldListModel = ... in your code?

pMoldListModel isn't hidden by a local variable?

You always operate on the same instance of your class?

Have you tried to allocate the TreeView dynamically
with Gtk::manage(new Gtk::TreeView) in your ctor?

What does tvMoldList.get_model() yield by the time
pMoldListModel is 0?

It strikes me as strange that the model data member (pMoldListModel)
loose it's value between method calls.  You would think that it would
maintain it's value so that you could manipulate the model for the
of the object.

What do you think?  Is this in fact the expected behavior of the
Gtk::ListStore classes?

No, absolutely not. RefPtr<> aquires a reference on the ListStore.
The ListStore will not be freed until the last reference has become
out of scope. You could try to assign pMoldListModel to a global
variable (so that two reference with a completely different scope
refer to the same ListModel) and see if anything changes.

I'm sorry, without a compilable example we can only do guesswork.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]