Yay!! It seems there were two problems. One was that we were responding to the wrong signal. Thanks so much for this info!
The resulting data revealed a deeper pathology. I had mentioned that output at the beginning of the _view_rebuild() method confirmed that it was not being called in the middle of executing reflect_view(). I was concerned with some manipulation of self accidentally calling _view_rebuild()...but what I hadn't thought of was _view_rebuild() causing row_changed signals! heehee My quick but ugly solution is to use a member to lock reflect_view() when _view_rebuild() is executing. If we must have ugliness, at least it's contained ugliness :) But really, anybody have any better ways to prevent that? Thank you so much, Doug, Christian, and Yang, for helping me figure this out. I hadn't mentioned it, but my deadline is tommorow and I probably would have missed it were it not for you folks. You rock! G'night. -- David McCabe PGP Key ID: 0xBD6B3B4E 41E5DD0466B3C3EFFAC6977DD5B80608BD6B3B4E
signature.asc
Description: Digital signature
_______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
