On Thu, Nov 26, 2009 at 2:55 AM, Chris Howie <[email protected]> wrote: > On Thu, Nov 26, 2009 at 12:21 AM, Chuck Esterbrook > <[email protected]> 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 hashtable! 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: http://stackoverflow.com/questions/1058635/common-uses-for-the-tag-property 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: http://www.go-mono.com/docs/index.aspx?link=P%3aGLib.Object.Data 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 either. I've CCed [email protected] 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 tag). -Chuck _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
