It does look a lot like specifying actions is hard-coded for controls and cells.

Nearest I can think of is to use the "User Defined Runtime Attributes" in the 
Identity Inspector (Command-6 in Xcode 3). Add a string property called 
actionName. Have setActionName: call setAction:, and have the actionName getter 
call NSStringFromSelector([self action]).

In IB, you'd have to hit the "+" button to add an actionName value to your 
view, but you can make a keyboard macro that does most of the work:

Command-1 Command-6 (init keyboard focus)
Tab Tab Tab Tab Tab Tab Space (press the "+" button)
actionName Tab (enter the name of the actionName property)
Space Str Return Tab (select "String" as the property type)
myAction: Command-A (enter a placeholder for you to replace with your own 
action name)

You don't get the benefit of IB validation that the action method exists, but 
you could add code that checks at runtime, which is the next best thing.

It'd be nice if there were a way to specify that you want a property to show up 
in IB as one of the "User Defined Runtime Attributes", sort of the way IBOutlet 
indicates a property or ivar is an outlet. If/when I get around to filing a 
request for this I'll post the Radar number.

Another idea for a Radar: have IB provide the action-specifying UI for any 
object that has target and action properties, not just controls and cells.

I don't know if Xcode 4 makes any of the above less cumbersome or contortional. 
In any case, this is all I can think of.

--Andy

On Dec 1, 2011, at 10:23 PM, Graham Cox wrote:

> I have some custom views that act in some ways like lightweight controls - 
> they have target and action properties - but they inherit NSView, not 
> NSControl.
> 
> It would be useful to be able to allow the targets and actions of these views 
> to be hooked up in IB. Target isn't usually a problem - it can be an outlet. 
> But the action is another matter, IB can't "see" it, so doesn't allow me to 
> specify the selector. Am I missing something or this a feature that is 
> hard-coded into IB and not available to custom views?
> 
> I'd rather not subclass NSControl, because that would compromise the 
> simplicity and lightness of these views just to allow an action to be set - 
> NSControl brings in way too much other baggage as well.
> 
> --Graham
> 
> 
> _______________________________________________
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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/aglee%40mac.com
> 
> This email sent to ag...@mac.com

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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 arch...@mail-archive.com

Reply via email to