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

Todd Berman tberman@off.net
Wed, 17 Nov 2004 11:04:34 -0800

On Wed, 2004-11-17 at 11:03 +0000, Mike Rhodes wrote:
> 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.

Are you calling Gdk.Threads.Init ()?

Using the Gdk.Threads.* functions should be a last last last resort.

> 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...

Look at Gdk.Global.

> 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.

You can just use GLib.IdleHandler.Add and delegates to do it, which is
far less wasteful.

ThreadNotify was originally a hack, that did some gio notification to
basically cause what GLib.IdleHandler does. It was platform specific
(p/invoked into libc) and generally not good. However, instead of
removing that bit of API, we updated it to use the GLib.IdleHandler. At
this point (imo) ThreadNotify exists only to provide API that is not
only in use, but also spoken about on this list and others.

> 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.

Absolutely it is a thread issue.

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

If that was the case, it wouldn't update when you moved your mouse near
it, or did some sort of action.

> Mike.
> > 
> > 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.

Ok. Fine. You should *NEVER* need to call EmitRowChanged in code using a
TreeView. EmitRowChanged (I believe) exists for custom TreeModels. (Not