Chris Lambacher <[EMAIL PROTECTED]> writes:
> if iter does not override the __nonzero__ method from object, the
> while loop will always evaluate iter as true. The documenation says
> that listtstore.remove sets iter to the next valid row so the original
> unless it is the last row in which case the iter is invalidated. so
> the while loop needs to check if iter is valid using
> liststore.iter_is_valid:
>
> while self.lstore.iter_is_valid(iter):
> self.lstore.remove(iter)
>
> if remove invalidates iter rather than setting it to the next line,
> the documentation needs to be updated.
I think the docs are wrong and remove(iter) won't advance the iter.
In the C API, iter is a reference parameter. This is a handy C idiom
but it's pretty hostile to bindings. In order to advance the iter you
need to call iter_next().
You have to be careful though, because this won't work:
# don't do this
while self.lstore.iter_is_valid(iter):
iter = self.lststore.iter_next(iter)
The iter_next() method returns None when applied to an iter to the
last row, so ultimately when you run off the end of the list you will
get an error because None isn't a GtkTreeIter:
>>> self.lstore.iter_is_valid(None)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: iter should be a GtkTreeIter
The original "while iter:" test is good and it's almost always what
you want. In normal use your iters will come from get_iter_first(),
iter_next() and append() and the like. The iters should always be
valid or None unless you remove the row they refer to. Since you're
the one removing the row you know when the iter isn't valid -- there's
rarely a need to test.
# A slow way to do self.lstore.clear()
iter = self.lstore.get_iter_first()
while iter:
next = self.lstore.iter_next(iter)
self.lstore.remove(iter)
iter = next
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
