Welcome to the MacNN Forums.

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

You are here: MacNN Forums > Software - Troubleshooting and Discussion > Developer Center > Dynamically created NSTabViewItems?

Dynamically created NSTabViewItems?
Thread Tools
Fresh-Faced Recruit
Join Date: Jan 2002
Status: Offline
Reply With Quote
Jan 24, 2002, 11:46 PM
I was just fiddling around in PB/IB and I wanted to see if I could add NSTabViewItems to an NSTabView on the fly. I created the NSTabView and a template NSTabViewItem at index 0. Then I used the following code:

<BLOCKQUOTE><font size="1"face="Geneva, Verdana, Arial">code:</font><HR><pre><font size=1 face=courier>
<font color = brown>// tabPanel is an outlet of my controller class</font>
NSTabViewItem *myItem;
myItem = [[NSTabViewItem alloc] initWithIdentifier:nil];
[myItem setLabel:<font color = orange>@"test"</font>];
[myItem setView:[[[tabPanel tabViewItemAtIndex: <font color = blue>0</font>] view] copy]];
[tabPanel addTabViewItem: myItem];

However, when running it, it told me that the NSView class does not conform to the NSCopying protocol. I also tried just using sending the copy message to NSTabViewItem, but it also does not support copying. Does anyone have any ideas?

Thanks in advance.
Yeah, Jesus saves. But so do coupons, and we don't worship them.
Dedicated MacNNer
Join Date: Jun 2000
Location: Dundas, Ontario, Canada
Status: Offline
Reply With Quote
Jan 25, 2002, 01:37 PM
I dealt with something like this recently with some toolbar view items and the solution is simple yet a little tedious.

The problem with your code is that you are attempting to send a copy instruction to a subclass of NSView. Since it does not support the copying protocol, you can't do this. Also, you can't make that same view the contents of multiple tabs since each view can have only one superview.

Essentially, you have to implement some manual copying by extracting the frame and other useful information about the view you want to copy and programmatically reproduce another one with those same attributes (hence the tedious I mentioned).

If you omit the line that adds the view to the NSTabViewItem this will work properly and your program will dynamically create the tab but it won't have anything in it.

Hope that helps,
Spectral Class
"Shedding Light on Innovation"
Professional Poster
Join Date: Dec 2000
Location: Chicago, Illinois
Status: Offline
Reply With Quote
Jan 25, 2002, 01:57 PM
That's really silly. On the java side, I would just send my view a clone() call and be done with the whole matter. At least.... I think that would work. It should, but I've really only done it on subclasses of NSObject that weren't also a subclass of NSView. There should be a similar way to do this in Obj-C... maybe Archive the view and then unarchive it?

Dedicated MacNNer
Join Date: Jun 2000
Location: Dundas, Ontario, Canada
Status: Offline
Reply With Quote
Jan 25, 2002, 03:02 PM
Actually archiving and unarchiving would probably work. Someone recommended to me that I put these views I need over and over in a nib and then load it whenever I need a new one.

The problem with any set-in-stone ideas for copying views is that it forces them to become very static entities. For example, it my TIFF Tuner application I recently released a public alpha of, I needed to make the toolbars all use one view by reference (it has mutable properties that need to carry to all toolbar instances). If I had used an actual "copy" method this would not have been possible since I would have to change each instance of the toolbar manually afterwards. To be more specific, I had to change an NSPopUpButton contents on each toolbar. Since I could manually decide how to copy it, I was able to make them each share the same menu contents instance. This allowed one change to effect all other toolbars without any extra work.

Had their been a basic view copying method, I could not have used it anyway, due to this limitation. However, it would have taken much longer to find the problem than it did.

I know that this argument could be applied to any type of object that needs members by reference but I think that view objects have more of a real-world reasoning for this since they have special UI rules that other types are exempt from.

Does that sound reasonable?
Spectral Class
"Shedding Light on Innovation"
Dedicated MacNNer
Join Date: Jan 2001
Location: Virginia, US
Status: Offline
Reply With Quote
Jan 29, 2002, 12:55 AM
Implementing a copy-type method for anything that implements NSCoding
is really easy. Here's a category on NSObject that does it...

<BLOCKQUOTE><font size="1"face="Geneva, Verdana, Arial">code:</font><HR><pre><font size=1 face=courier>
@implementation NSObject (ArchiveCopy)
<font color = brown>/*"
* Returns a copy of the receive using NSArchiver. The returned object is
* retained, like a regular copy. Raises if the receiver does not conform to the
* NSCoding protocol.
- (id)archiveCopy
NSData *archiveData;

if (![self conformsToProtocol:@protocol(NSCoding)])
[NSException raise:NSGenericException format:<font color = orange>@"Class %@ does not conform to NSCoding"</font>, NSStringFromClass([self class])];

archiveData = [NSArchiver archivedDataWithRootObject:self];
return [[NSUnarchiver unarchiveObjectWithData:archiveData] retain];
Thread Tools
Forum Links
Forum Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Privacy Policy
All times are GMT -4. The time now is 11:48 AM.
All contents of these forums © 1995-2017 MacNN. All rights reserved.
Branding + Design: www.gesamtbild.com
vBulletin v.3.8.8 © 2000-2017, Jelsoft Enterprises Ltd.,