On Jul 29, 2006, at 8:45 AM, Wagner Truppel wrote:
I am attempting to write an IB palette for a custom subclass of
NSTabView. Since there's no public access to NSTabViewInspector.h,
I've had to implement much of the existing standard functionality.
In particular, I've had to implement changing the number of
NSTabViewItems.
Everything works with the exception of one not-so-small detail:
when I add new NSTabViewItems, the custom NSTabView subclass is
updated as expected and new NSTabViewItem objects appear, but when
I single-click on them, I get the regular (non-IB) behavior,
namely, the tabs are selected (and the views under them are
switched in) just as if I was running in simulation mode. The same
thing happens if I double-click on them.
But I'm not yet in simulation mode. I'm still in editing/design
mode, and I should be getting the behavior that, upon single-
clicking, the view under an NSTabViewItem should be activated so
that I can drag controls from the IB palettes into it. Moreover,
when double-clicking on a NSTabViewItem, its label should enter
edit mode.
The relevant bit of (pseudo) code is as follows:
in the -(void)ok:(id)sender method, I check whether the user is
requesting more items
if so, then repeat the following as many times as necessary
{
NSString *label = [NSString stringWithFormat :@"Tab %i", index];
NSString *identifier = [NSString stringWithFormat :@"%i", index];
where index increases by one with every iteration. This works fine
to get the custom TabView to display new NSTabViewItem objects, but
how do I make those new objects respond to mouse clicks in the same
way as those added when using the standard NSTabView palette?
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
