thank you for replying so quickly. I like the simplicity of your
solution and I'm now inclined to implement my palette that way, but
I'm still curious as to how to solve the problem with an approach
along the lines of what I've done so far. I'm fairly new at Cocoa and
I'm trying to understand what is missing in my current approach.
Thanks again.
Wagner
On Jul 29, 2006, at 6:55 AM, Ricky Sharp wrote:
One thing you could do is have your NSTabView subclass implement a
protocol. Methods on the protocol would be the accessors for the
additional attributes the subclass would have, along with any other
support API. Then, in your palette's willInspectObject: method, do
something like this:
- (void)willInspectObject:(NSNotification*)aNotification
{
id theObject = [aNotification object];
You then do _not_ implement the inspectorClassName method on the
subclass of NSTabView.
So, whenever an instance of your subclass is selected in IB, you
should then see the default NSTabView inspector and then gain an
additional inspector pane (appended to the end of popup menu item
list; hence the -1.0 ordering) to handle your additional attributes.
The really nice thing about this approach is that if Apple ever
adds other attributes to NSTabView over time, you'll gain access to
those without modifications to your palette since you're now using
two inspectors (default Apple-supplied inspector, plus one to
handle your additions).
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
