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

[John Luke]

Hey,

How about somebody (hopefully Todd) writes a more thorough explanation
for Gtk.ThreadNotify and the related Gdk.Thread stuff and puts it in
monodoc.  Especially if the other solutions are subpar it would be
nice to point from them to Gtk.ThreadNotify.  If I'm not mistaken the
current stuff is just a 'port' from the GTK+ docs and needs someone to
update to be more accurate for Gtk#.

Then perhaps we can answer less questions on the list over and over,
or at least refer to the docs.  It would probably only take this
person about 15 minutes to do so.

On Wed, 17 Nov 2004 11:04:34 -0800, Todd Berman <tberman@off.net> wrote:
> 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
> 100%).
> 
> --Todd
> 
> 
> 
> _______________________________________________
> Gtk-sharp-list maillist  -  Gtk-sharp-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
>