[Gtk-sharp-list] Associate user data object with a widget
christian_hoff at gmx.net
Thu Nov 26 12:37:18 EST 2009
GLib.Object.Data is deprecated according to the docs, but it is not
marked obsolete in the code for whatever reason. Maybe this decision has
been reverted and the docs have not been updated yet.
In any case, that means that it won't be removed in Gtk# 3.0. Any
thoughts on this issue, Mike?
Chuck Esterbrook wrote:
> On Thu, Nov 26, 2009 at 2:55 AM, Chris Howie <cdhowie at gmail.com> wrote:
>> On Thu, Nov 26, 2009 at 12:21 AM, Chuck Esterbrook
>> <chuck.esterbrook at gmail.com> wrote:
>>> I'd like to associate an arbitrary Mono/.NET object with a widget.
>>> Something like:
>>> button.Data = "foo"
>>> menuItem.Data = new MyClass();
>> There are two options here...
>> 1. Create a Dictionary<Widget, T> (you pick the T according to your
>> needs) and use that dictionary to map widgets to the data you want to
>> associate with them.
>> 2. Derive the widget classes and create a property on them for your needs.
> I agree that these appear to be the only techniques available.
>> The reason that the "user data" mechanism is marked obsolete is
>> because it's completely the wrong way to model something like this and
>> usually creates more problems than it solves.
> Putting a value in a hashtable owned by an object isn't much different
> than putting a value in a variable owned by the object. In fact, some
> languages like Python even store their object variables using a
> There are several GUI framework authors who think user data is okay
> given that GUI libs tend to have this feature including GTK+,
> WinForms, WPF and Silverlight. See also:
> I've used this technique in other GUI libs without experiencing a
> single problem. It's just an alternate way to stash data in an
> existing object.
> While we're still talking about this, I find the docs strange. They
> say "This property is obsolete and should not be used unless you
> explicitly retain a reference to the GLib.Object. Otherwise the Data
> hashtable will be lost when the Garbage Collector releases your
> managed object wrapper." at:
> But my response is... So what? In the VM you are retaining a reference
> to an object while you are interested in it. And losing the data
> hashtable reference upon losing the managed object is not a problem
> I've CCed mkestner at novell.com in case he wants to comment as he marked
> this obsolete in 2004-12. I wonder if it was marked so because of a
> bug, such as an unresolved integration issue. I haven't looked at the
> implementation yet.
> I still find it strange that if I use a higher level language, like
> C#, instead of C, I lose this feature (at least if I heed the obsolete
> Gtk-sharp-list maillist - Gtk-sharp-list at lists.ximian.com
More information about the Gtk-sharp-list