On 26/02/2009, at 1:36 PM, Walker Argendeli wrote:
I didn't want a plethora of functions though, so I used code like
this, with the object id's coming from IB:
I don't think Object IDs assigned by IB are accessible to your code.
Same for the names used in IB to label things.
Most controls and UI items support a tag which is a simple integer
value that can be used for this purpose.
On a general note though, I'd say this is misguided. There are a few
times when differentiating based on tags is very useful, (like setting
the action of a whole menu to a single method, then using the tag to
tell which item was chosen). It makes for far more maintainable, clean
code if every distinct action has a distinct action method. It doesn't
matter if there are hundreds of them, at least they can be "wired up"
and debugged in isolation. Furthermore, by naming them descriptively,
wiring them up in IB takes seconds, because it's obvious which
function goes with which control. In IB3 this is easier than it was
because you can bring up a complete table of actions for a controller
and wire them all at once.
Also, many action methods necessarily must make assumptions about the
type of their sender - for example if the sender is a NSColorWell your
action method can call [sender color] without checking for the sender
actually implementing it because it "knows" it is uniquely wired to a
NSColorWell object. A "one action method for all purposes" ends up
having to rigourously check that the sender responds to all sorts of
things, or else gets into the nasty business of testing for class
type. That way madness lies, and the amount of code is far more than
the amount you saved by not writing separate action method in the
first place.
I must admit when I first started with Cocoa I tried to avoid writing
too many action methods - it seemed like a chore. Now I've a few more
years' experience under my belt, my controllers typically have many
action methods, usually one per distinct control. About the only time
more than one control funnels into the same action method is when they
genuinely do the same job, for example a slider, textfield and stepper
all setting the same parameter as a kind of "triple input" interface.
Here's an example of a typical controller in my app. I have many
hundreds of similar classes that look much the same. In IB I don't
have to refer to the class to know how to wire up both outlets and
actions - the names of everything tells me all I need to know.
@interface DKOTextAdornmentController : DKORasterizerController
{
IBOutlet NSTextField* mIdentifierTextField;
IBOutlet NSComboBox* mIdentifierComboBox;
IBOutlet NSTextField* mLabelTextField;
IBOutlet NSButton* mFontPanelButton;
IBOutlet NSPopUpButton* mLayoutModePopUpButton;
IBOutlet NSPopUpButton* mVerticalPositionPopUpButton;
IBOutlet NSSlider* mVerticalPositionSlider;
IBOutlet NSSlider* mAngleSlider;
IBOutlet NSTextField* mAngleTextField;
IBOutlet NSStepper* mAngleStepper;
IBOutlet NSButton* mClipToPathCheckbox;
IBOutlet NSButton* mRelativeAngleCheckbox;
IBOutlet NSButton* mWrapLinesCheckbox;
IBOutlet NSColorWell* mTextColourWell;
IBOutlet NSColorWell* mTextOutlineColourWell;
IBOutlet NSButton* mTextOutlineEnableCheckbox;
IBOutlet NSSlider* mTextOutlineWidthSlider;
IBOutlet NSTextField* mTextOutlineWidthTextField;
IBOutlet NSStepper* mTextOutlineWidthStepper;
IBOutlet NSSegmentedControl* mParagraphAlignmentControl;
}
- (IBAction) identifierAction:(id) sender;
- (IBAction) labelAction:(id) sender;
- (IBAction) fontPanelButtonAction:(id) sender;
- (IBAction) layoutModeAction:(id) sender;
- (IBAction) verticalPositionModeAction:(id) sender;
- (IBAction) verticalPositionAction:(id) sender;
- (IBAction) angleAction:(id) sender;
- (IBAction) relativeAngleAction:(id) sender;
- (IBAction) wrapLinesAction:(id) sender;
- (IBAction) textColourAction:(id) sender;
- (IBAction) paragraphAlignmentAction:(id) sender;
- (IBAction) textOutlineColourAction:(id) sender;
- (IBAction) textOutlineEnableAction:(id) sender;
- (IBAction) textOutlineWidthAction:(id) sender;
// other stuff
@end
_______________________________________________
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
