On 24/02/2011, at 6:17 PM, Trygve Inda wrote: >> >> On 24/02/2011, at 5:56 PM, Trygve Inda wrote: >> >>> The problem is two-fold: >>> >>> 1) How can I have nibs, one with MyObjectClass:NSObject and the other with >>> MyObjectClass:NSPreferencePane where MyObjectClass is essentially the same >>> but with a few #ifdef to have conditional compilation. >> >> The real problem is that you're trying to define this chimera class in the >> same header. If you split it into two separate headers, each nib only needs >> to >> know about the header that applies to it. Target Membership will do the rest, >> since the right nib and the right header are part of the same target and >> there's no crosstalk to the other target. > > How would I split it into two headers? > > In my .m file I can certainly use #ifdef to import the correct .h file, but > IB is still going to see one header with:
Just have two completely different classes as per usual, each importing their own header. Use Target Membership to select the one that gets compiled for the app. Even if there is a certain amount of duplicate code in the two, only one ends up in your binary. If this offends your sense of neatness, move the common code into a helper class each object uses. > @interface MyObjectClass : NSPreferencePane > > And another with > > @interface MyObjectClass : NSObject I don't see why IB would have a problem. It's two separate nib files, which as far as it is concerned have no relationship to each other other than belonging to the same project (name them differently also). When you set the class of Files Owner, it reads the header for that class, which is one of the two. It can't be confused by the other header, because it doesn't know it's anything to do with this nib (because it's not, the other header is Files Owner for the alternate nib). >> Just make the outlets type id and they can point to anything. > > IBOutlet id controllerA; > IBOutlet id controllerB; > IBOutlet id controllerC; > > In this case I'd no longer be able to get warnings like "someMethod is not > defined on class controllerA" Well, I guess you might have to accept some sacrifices trying to build two fairly different kinds of executable from common code. You could declare the common methods to be part of an informal or formal protocol adopted by both classes. A formal protocol would be nice, in that you can do IBOutlet id<MyCommonProtocol> and there would be no warnings but you still get type checking. If informal, it won't give warnings either as long as the informal protocol is visible at compile time to the code for A, B and C. The compiler doesn't know if your anon object implements the informal protocol or not, but since it knows the protocol is a possibility, it keeps quiet. --Graham _______________________________________________ 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
