[Gtk-sharp-list] Refresh of elements in a treeview

Mike Rhodes Mike Rhodes <mike.rhodes@gmail.com>
Wed, 17 Nov 2004 11:03:04 +0000

My apologies for not being clear.  The call to EmitRowChanged() is
wrapped using Gdk.Threads.Enter() and Leave(). According to the docs
(and other posts to this list), this should cause my thread to
temporarily hold the lock so I can safety access the Gtk objects
whilst in the other thread.

On further reading of the docs, I note that they say you should call
gdk_flush() to flush the pending operations prior to calling Leave().
Is this a throwback C function? I can find it in the gtk+ docs, but
not an equivalent in the gtk# ones...

On another note, I recall someone mentioning Enter/Leave were not the
preferred method to do this any more, but not that they would cause
breakages and weird behavior if used. However, it seems a little
wasteful to create a ThreadNotify object and call for each of these
small events.

Exactly the same behavior happens whether or not the calls have the
Enter/Leave pair around them, so whether it is a thread issue I'm not
even sure.

Could it be because I'm modifying an object packed into the model
rather than the contents of the model itself?


> You should *NEVER* need to call EmitRowChanged when you add stuff to the
> treemodel.

I'm not adding stuff here, just modifying an object I have packed into
the tree already.

On Tue, 16 Nov 2004 18:13:24 -0600, Mike Kestner <mkestner@ximian.com> wrote:
> On Tue, 2004-11-16 at 22:10 +0000, Mike Rhodes wrote:
> > In basic terms, I have several items that I add to a treeview. I then
> > start a thread that updates these items with more detailed information
> > that needs to be drawn into the treeview to replace the current data.
> Key phrase being, "start a thread."  As has been mention on this list
> numerous times, and is listed in the FAQ:
> http://gtk-sharp.sourceforge.net/faq.html#3.5
> you can not update GUI elements from a thread other than the main gui
> thread.  Doing so will cause badness.
> --
> Mike Kestner <mkestner@ximian.com>

"One should not aim at being possible to 
understand but at being impossible to
misunderstand." - Quintilian