Re: One IBAction, multiple results from multiple methods
Re: One IBAction, multiple results from multiple methods
- Subject: Re: One IBAction, multiple results from multiple methods
- From: Andy Lee <email@hidden>
- Date: Thu, 26 Feb 2009 14:39:59 -0500
On Feb 26, 2009, at 2:20 PM, Paul Sanders wrote:
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.
Again, just to be clear, I'm not advocating against anything,
certainly not advocating against symbolic tags in general, just
offering a different approach I might have taken for the particular
exercise that Dave described. If there had been three buttons instead
of a hundred, I would probably have just wired them up in IB.
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.
I don't understand why you think that. My approach has absolutely
nothing to do with the size or layout of anything.
--Andy
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden