> > On 25/02/2011, at 7:16 AM, Trygve Inda wrote: > >> I am guessing IB is reading the MyClass.m which has both .h files imported >> with #ifdef > > > I don't think this is true - I have sometimes defined the header for a class > and then set up the interface in IB using that header before I've even written > a line in the .m file. IB seems quite happy, though at that point XCode > wouldn't be if I tried to compile. > > I'm not sure why you're even doing this. Just keep the two .m files totally > separate, reading their own header file as is the usual case. If there's code > common to both that you are uncomfortable duplicating, move it into a common > helper class used by both. > > --Graham > > >
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. _______________________________________________ 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
