Re: How to delete a multiple selection from a ListStore?

["Joost Ellerbroek" <j ellerbroek gmail com>]

It works, thanks for the tip!
This way I don't have to iterate over the complete model just to delete the selection.
Should be more efficient :)

cheers,

Joost

ps. I suppose this might be something for the gtkmm wiki? I suppose it's possible to post examples there?

On 8/8/06, Edward Leaver <eleaver sterlingseismic com> wrote:

I've been down this rat hole and believe Caryl is correct. Here's a
snippet from some working code:
..................................................
Glib::RefPtr<Gtk::TreeStore> ref_selected_treestore =
RefPtr<Gtk::TreeStore>::cast_static(selected_treeview->get_model());

list<TreePath> selected_paths =
selected_treeview->get_selection()->get_selected_rows();

vector<TreeRowReference> selected_refs;
for(list<TreePath>::const_iterator piter = selected_paths.begin();
          piter!=selected_paths.end(); piter++){
selected_refs.push_back(TreeRowReference(selected_treeview->get_model(),
*piter));
}
for(vector<TreeRowReference>::reverse_iterator riter =
selected_refs.rbegin(); riter!=selected_refs.rend(); riter++){
   TreeIter dead_row_iter
= ref_selected_treestore->get_iter(riter->get_path());
        ref_selected_treestore->erase(dead_row_iter);
}
...............................................................
Note that although the TreeRowReference takes a TreePath as its
constructor parameter, that does not necessarily mean that a TreePath is
what it is. Note also (for this reason) that I convert *all* the
selected paths to references *before* I erase *any* of them. And I erase
them in reverse order "just to make sure."

(Also, I actually embed the row erase(dead_row_iter) inside another
function that does some additional bookkeeping on the remaining parent
nodes in the treestore; I hope this version compiles OK.)

Hope this helps, it thus far works for me.

Ed



On Tue, 2006-08-08 at 08:49 -0500, Robert Caryl wrote:
> According to the docs, a path stored in the RowReference continually
> points to the same row it did when it was created (so long as that row
> continues to exist) even when the TreeModel is modified (by adding or
> deleting rows); hence, you derive an iter from the Gtk::TreeModel::Path
> provided by the RowReference and then use erase to rid yourself of the
> row in question.   I am assuming that you know how to get an iter from a
> Gtk::TreeModel::Path.
>
> Bob Caryl
>
> Joost Ellerbroek wrote:
> > I don't get how your RowReferences method would work, you need a
> > TreeIter for the erase method, don't you?
> > My second method does work though; is it terribly inefficient, or do
> > you think I'll survive? :)
> >
> > Joost
> >
> > On 8/8/06, Murray Cumming < murrayc murrayc com> wrote:
> >>
> >> > Convert your original list of selected rows into a list of
> >> > Gtk::TreeModel::RowReferences.  Using this list you can use the
> >> paths it
> >> > contains when you loop through the list calling the model's erase
> >> > method.  The path each Gtk::TreeModel::RowReference contains remains
> >> > valid so long as the row to which it points exists regardless of the
> >> > fact that you are changing the model by deleting rows.
> >>
> >> I've never quite understood the need for this class. A path is already
> >> only a potential path. When you convert it to an iter then the iter will
> >> be invalid if the path isn't valid at that time. (In the example code,
> >> he's not checking the result of get_iter(), I see.)
> >>
> >> And if we were just storing paths then the paths wouldn't indicate the
> >> same rows if we have deleted the rows before the intended row.
> >>
> >> Maybe RowReference always provides a valid (at the time, sometimes
> >> different than originally) path.
> >>
> >>
> >> Murray Cumming
> >> murrayc murrayc com
> >> www.murrayc.com
> >> www.openismus.com
> >>
> >>
> >
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>