On 25/02/2011, at 10:26 AM, Trygve Inda wrote: > It seems to be pretty random when using two header files, but a common > implementation. There should be a way to drag a header to IB and have it > reinterpret the class, but it just complains that the superclass is wrong. > > I guess the issue here is that if I make them separate classes, then the > common classes can only link to them by id and not by a real type. > > @interface MyRetailClass : NSPreferencePane > @interface MyAppStoreClass : NSObject > > Then in my common classes: > > ClassA > ClassB > ClassC > > I have to do > > IBOutlet id mainClass; > > Instead of > > IBOutlet MyRetailClass* mainClass; > > Or > > IBOutlet MyAppStoreClass* mainClass; > > So when ClassA does [mainClass someArray] as an accessor, I don't get the > same compiler checking I would have with explicit classes. But with explicit > classes, I can't properly connect the objects in IB in both versions.
So use a formal protocol: @interface MyRetailClass : NSPreferencePane<MyCommonProtocol> @interface MyAppStoreClass : NSObject<MyCommonProtocol> Then in A, B and C have: IBOutlet id<MyCommonProtocol> mainClass; Thus you can connect the outlet to any object that implements the MyCommonProtocol protocol. I'm not sure how far IB will go to check protocols, but in any case there isn't really much chance you'll make a mistake here is there? I mean, you know how these things are meant to go together. Type checking is great and all, but it's no substitute for common sense. --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
