> I see how something like this could be convenient, so I'm not trying > to shoot the IBTag idea down, but in this example I wouldn't enter the > tags manually in IB. I'd put all 100 buttons in an NSView, have an > outlet to the NSView in my controller, and have awakeFromNib set up > all the buttons programmatically by looping through the NSView's > subviews. For each button it would set the target and action, and it > would set the tag by converting the button's title to a keycode > through a lookup table I'd hardcode. This would save me a lot of > Control-drags and tedious typing for each button -- I'd rather do the > tedious typing in code. I wouldn't worry so much about the meaning > (or existence) of the tag being obvious from inspecting a button in > IB. Some future person poking around should know to look in the code > when they see that none of the buttons have targets in IB.
> --Andy There seems to me to be an overwhelming case for supporting symbolic tags in IB. It sounds easy to do, has no downside that I can see and having the flexibility to identify controls and menu items via a (symbolic) tag can only be a good thing. I am currently looking to port my Windows app to Cocoa while maintaining a common code base, and having symbolic tags would be an enormous plus for me as all my existing Windows code identifies controls and menu items in this way. As it is, I have a tricky problem to deal with which IB could so easily solve. And your suggestion would not let Dave lay his keyboard out to look like the real thing Andy. Not easily, anyway. The code would need to know things like the size of the space bar for example. _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
