Re: Gtk::TreeModel oddity
- From: Bob Caryl <bob fis-cal com>
- To: Murray Cumming <murrayc murrayc com>
- Cc: gtkmm-list <gtkmm-list gnome org>
- Subject: Re: Gtk::TreeModel oddity
- Date: Wed, 27 Apr 2005 10:58:00 -0500
Murray Cumming wrote:
On Wed, 2005-04-27 at 10:11 -0500, Bob Caryl wrote:
Hello all,
I have an application where I use a Gtk::ListStore in conjunction with a
Gtk::TreeView to display representations of records in a database. I
have a function whereby the user can delete database records by clicking
on one of those representations and pressing a button. In the function
connected to that button, I use the following code to remove the list
store entry representing the deleted database record and to set the Tree
View cursor:
Glib::RefPtr<Gtk::ListStore> list; // our
listore object for the treeview
Glib::RefPtr<Gtk::TreeSelection> list_sel; // selection
for the treeview
Gtk::TreeModel::Path *path = new
Gtk::TreeModel::Path(list->erase(list_sel->get_selected())); // obtain
path to the row following the deleted row
I'd start by checking the result of get_selectd(), and the result of
erase() for validity, with if(iter).
if(path) // if the path is valid set the view cursor to that path.
{
tree->set_cursor(*path);
delete path;
}
This code works (e.g. the row in the TreeView disappears and the cursor
is repositioned on the following row), but I get several "Critical"
messages:
(gmwadmin:2454): Gtk-CRITICAL **: gtk_list_store_get_value: assertion
`GTK_LIST_STORE (tree_model)->stamp == iter->stamp' failed
This normally means that the iterator is from a different treemodel.
Maybe you are using a different model here by mistake.
(gmwadmin:2454): GLib-GObject-CRITICAL **: g_value_get_string: assertion
`G_VALUE_HOLDS_STRING (value)' failed
(gmwadmin:2454): GLib-GObject-CRITICAL **: g_value_unset: assertion
`G_IS_VALUE (value)' failed
(gmwadmin:2454): Gtk-CRITICAL **: gtk_list_store_get_path: assertion
`iter->stamp == GTK_LIST_STORE (tree_model)->stamp' failed
(gmwadmin:2454): Gtk-CRITICAL **: gtk_tree_view_set_cursor_on_cell:
assertion `path != NULL' failed
Using the de-bugger I have determined that the call to "list->erase" is
generating these messages. The messages tend to make me think that
the iterator returned by the Gtk::TreeSelection::get_selected function
is not the same type of iterator required by the Gtk::ListStore::erase
function as its formal parameter. However, the docs don't seem to make
a distinction between the iterators they describe as return values and
formal parameters (in other words, following the hyperlinks in the docs
to the iterators go to the same page). I *think* I have implemented the
foregoing code properly based on the gtkmm docs, but maybe I have not...
can someone please point out my error?
Best regards,
Bob Caryl
_______________________________________________
gtkmm-list mailing list
gtkmm-list gnome org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Ok... I am using only one view and one model so I think it's safe to
rule out the possibility of the iterators being from different models.
I have modified my code per your suggestion as follows:
Gtk::TreeModel::iterator iter1 = table_sel->get_selected();
if(iter1)
{
Gtk::TreeModel::iterator iter2 = list->erase(iter);
if(iter2)
{
Gtk::TreeModel::Path *path = new Gtk::TreeModel::Path(iter2);
if(path)
{
tree->set_cursor(*path);
delete path;
}
}
}
Running this code in the debugger shows that both "if(iter)" statements
produce true results and the Gtk::ListStore::erasse function still
produces the following critical messages:
(gmwadmin:2784): Gtk-CRITICAL **: gtk_list_store_get_value: assertion
`GTK_LIST_STORE (tree_model)->stamp == iter->stamp' failed
(gmwadmin:2784): GLib-GObject-CRITICAL **: g_value_get_string: assertion
`G_VALUE_HOLDS_STRING (value)' failed
(gmwadmin:2784): GLib-GObject-CRITICAL **: g_value_unset: assertion
`G_IS_VALUE (value)' failed
Yet, the cursor still gets set properly in the View!!! I suppose I can
ignore these messages since still get my cursor set.. but I am just
paranoid about getting warnings when I compile me code, let alone
CRITICAL messages.
Best regards,
Bob Caryl
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]