[Gtk-sharp-list] Associate user data object with a widget

Chuck Esterbrook chuck.esterbrook at gmail.com
Thu Nov 26 06:37:35 EST 2009

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:
>> Hi,
>> I'd like to associate an arbitrary Mono/.NET object with a widget.
>> Something like:
>>    button.Data = "foo"
>> or:
>>    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


More information about the Gtk-sharp-list mailing list