views:

140

answers:

4

Hi,

In winforms/C# most all UI Controls have a .Tag tag, so like myButton.Tag = myObject; where the Tag property is an 'object' type so you can basically store any type of object. How might I accomplish this in Objective-C/Cocoa? do all UI elements have something like .Tag where I can store an NSObject or something? If so, can you please provide an example. Thanks so much!

Note: I did see the integer .Tag there, but I wanted an object tag. But I guess that doesn't exist. hoo well.

+1  A: 

NSControl does have a tag and related setTag: method. It's not used internally so you can store whatever you like in it - it only stores NSInteger values though.

All Cocoa controls inherit from NSControl.

Robert Christie
Just `tag` (no colon) :)
dreamlax
@cb160: UIKit is different from AppKit, although all `UIView`-s do have the `tag` property.
KennyTM
+1  A: 

There is the possibility to add a tag, it's an integer if I remember correctly.

This said, I'm pretty sure one never needs this functionality in Cocoa, because it just doesn't work this way.

If you really want to add information you might be interested in the runtime's ability to associate an object with another object.

Georg
You could use this in conjunction with a Category to define an objectTag property for NSControl, that would associate any one object with a control via a fixed "ObjectTag" key.
Kendall Helmstetter Gelner
Beware: associative references are only available in 3.1+ (if only 3.0 had them)
rpetrich
I liked Kendall's answer.
Shnitzel
+5  A: 

As Georg said, you can associate whatever object to another object using the Objective-C runtime, so you can associate an Object to a control if you really want.

But that is not really how a standard Cocoa program works. Instead, in Cocoa, the Model-View-Controller pattern and the Delegation are the standard idiom, and associating an object directly to a widget or a view is discouraged. Even for a very small program, you would at least create a Model-Controller (called usually the application delegate in the Cocoa jargon) which manages the data, and keep the view composed of the standard controls as is. Then the view and the model-controller interact via target/action and delegation.

Apple has a very nice discussion of design patterns prevalent in Cocoa, see here.

In general, when you move from one API(Winforms/C#) to another API(Cocoa/Objective-C), there are some similarities but also some differences. It is usually worth learning how things are done in that API, rather than trying to shoehorn what you're used to into a new situation. (Just to be clear, I'm not saying which API is inherently better; this discussion goes both ways!)

So, when you are in a situation:

To do X in API A, I know the idiom P works. I now want to do X in API B. How can I directly implement idiom P in API B?

I recommend you to ask

To do X in API B, what should I do? What's the idiom in API B?

instead.

Yuji
+1  A: 

CALayers have the ability to store arbitrary keys as part of their key-value coding machinery. Example:

CALayer *myLayer = [button layer];
// Storing a value
[layer setValue:@"World!" forKey:@"hello"];
// Retrieving a value
NSLog(@"Hello %@", [layer valueForKey:@"hello"]);

That being said, storing objects against user-interface elements violates the principle of the Model-View-Controller pattern; I would advise against it--a UIView or UIControl subclass would likely be better suited.

rpetrich