Re: guidelines/tutorial for implementing custom controls
Re: guidelines/tutorial for implementing custom controls
- Subject: Re: guidelines/tutorial for implementing custom controls
- From: Erik Buck <email@hidden>
- Date: Mon, 4 Aug 2008 21:28:14 -0400
Can anybody point me to some good tutorials/guides for implementing
custom controls?
Do you have some objection to the examples at developer.apple.com ?
http://developer.apple.com/samplecode/Clock_Control/index.html
http://developer.apple.com/samplecode/TrackBall/
http://developer.apple.com/samplecode/bMoviePalette/index.html
There are some fun third party samples:
http://www.sticksoftware.com/software/CircularSlider.html
http://developer.snowmintcs.com/controls/smdoubleslider/index.html
http://www.stepwise.com/Articles/Technical/NSCell.html
See also Omni Group
http://www.omnigroup.com/developer/
There are some custom controls in the DrawDemo for DrawKit
http://apptree.net/drawkit.htm
I've been reading the Cocoa Event Handling Guide, The reference and
accompanying conceptual guides for NSControl, NSCell, NSActionCell and
NSView, but I'm more confused than when I started.
Odd. Those are relevant documents.
If anyone could answer these more specific questions or point me to
good reference material I'd really appreciate it:
1. How does one setup the target/action mechanism for a custom
control, i.e. client code can call setAction: and setTarget: and have
these stored in the class? Does this come for free when you subclass
NSActionCell? Or is it more correct to implement these methods
yourself, in an NSView subclass? Or NSControl subclass?
Subclasses of NSControl already have target/action support and can be
connected via Interface Builder. You can also use NSActionCell
without NSControl but won't automatically get Interface Builder
interaction. Target action is also easy to implement on your own via
NSApplication's - (BOOL)sendAction:(SEL)anAction to:(id)aTarget from:
(id)sender method.
2. Is wrapping existing controls in a custom control class a good
idea? I.e. the custom control class is a container for a handful of
standard controls, configures them in an appropriate way, and presents
an interface to client code as if it were a single control, i.e. a
target-action mechanism, and public properties for querying the state
of the control?
I guess that would work. Why would you want to do that ?
My (current) higher level goal is implementing a control that includes
3 momentary buttons, the middle button showing a menu when pressed.
These buttons all edit one piece of data, a ratio. This control needs
to be invoked (i.e. added to parent view) from code and be reusable.
The client code needs to be informed when a button is clicked and be
able to query the control's current value. The new control is
responsible for the appearance, and the contents of the menu. In
future I will also need to implement more complex custom controls/
views, that include custom drawing and a handful of subcontrols (that
are all related and present a unified interface to client code).
I don't think you need a custom control to meet any of your goals.
Just embed your buttons etc. in a convenient parent view and provide
suitable Controller logic (ref: Model View Controller). You can save
your embedded views in their own interface builder nib file for reuse
or even add your pre-configured group of objects to Interface
Builder's library. See "Adding Modified Objects Back to the Library"
In Interface Builder's help.
You will need to subclass NSView or one of its existing subclasses
when you want custom drawing unless you use CALayer's instead.
I've noticed that NSSegmentedControl can implement pretty much all of
the control, so I think I want to use that internally, implementing
all the config for the segmented control, and mapping the actions of
the individual buttons to set the data in the control and invoke the
custom action (that the client code, the target receives).
Is there a way to achieve this? Am I barking up the wrong tree?
I think what you are suggesting is workable. Have you tried it ?
_______________________________________________
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