• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: IBOutlet to different classes, conditional build
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IBOutlet to different classes, conditional build


  • Subject: Re: IBOutlet to different classes, conditional build
  • From: Trygve Inda <email@hidden>
  • Date: Fri, 25 Feb 2011 00:17:08 +0000
  • Thread-topic: IBOutlet to different classes, conditional build

>
> 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.

So what file would I define this protocol in... The two .h files for the
unique classes? Each of the two classes has 12-16 methods and 10 of these
are common (and thus could be a protocol).

@protocol MyCommonProtocol

@optional
-(void)someMethod;
-(void)someotherMethod;
@end

It'd be nice if IB let me define a class two different ways and linked only
to the header file (which I should be able to replace in IB without a
"superclass mismatch warning"


_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden

  • Follow-Ups:
    • Re: IBOutlet to different classes, conditional build
      • From: Graham Cox <email@hidden>
References: 
 >Re: IBOutlet to different classes, conditional build (From: Graham Cox <email@hidden>)

  • Prev by Date: Re: IBOutlet to different classes, conditional build
  • Next by Date: Re: registerUndoWithTarget:selector:object: in or outside of group?
  • Previous by thread: Re: IBOutlet to different classes, conditional build
  • Next by thread: Re: IBOutlet to different classes, conditional build
  • Index(es):
    • Date
    • Thread