>>>> I have one project that outputs two binaries - one for the App Store (an >>>> app) and one for my own website version (a prefpane). >>>> >>>> All the classes are the same except for two: >>>> >>>> MyPrefPaneDelegate >>>> >>>> MyAppDelegate >>>> >>>> These are each in their respective apps. >>>> >>>> How can I build my shared classes so I can do: >>>> >>>> #ifdef RETAIL >>>> IBOutlet MyPrefPaneDelegate delegate >>>> #endif >>>> >>>> #ifdef APPSTORE >>>> IBOutlet MyAppDelegate delegate >>>> #endif >>>> >>>> >>>> It obviously compiles ok. But I have two nibs... One for the AppStore and >>>> one for the Retail version. My CommonClass is instantiated in both nibs, >>>> but >>>> in one case I need an outlet to point to a MyPrefPaneDelegate and in the >>>> other it needs to point to a MyAppDelegate >> >>> You can define a common superclass for both MyAppDelegate and MyPrefDelegate >>> - >>> MyCommonAppDelegate - and use that as the type of the IBOutlet. You can then >>> #define convenience delegates for each actual case, so you'd have something >>> like: >>> >>> IBOutlet MyCommonAppDelegate* commonDelegate; >>> >>> and then >>> >>> #ifdef RETAIL >>> #define delegate ((MyPrefPaneDelegate*) commonDelegate) >>> #endif >>> >>> #ifdef APPSTORE >>> #define delegate ((MyAppDelegate*) commonDelegate) >>> #endif >>> >>> Your superclass can even have the common code or it could be just an empty >>> "marker" to give both concrete classes a common type. Either way, everywhere >>> else you may continue to use delegate and never have to use commonDelegate. >>> Its only appearance would be where the above appears and in the nibs. >>> >>> And if you can't conveniently define a common superclass for both, define an >>> empty protocol that they both implement, then use that to define the >>> IBOutlet >>> instead. >>> >>> The point is, all you need is a common type for both classes. >>> > >> I guess the other issue is that if I do it this way the retail version needs >> to have IBAction methods for Sparkle updating which I need to keep out of >> the AppStore version... So how can I set it up so that one nib can have a >> button linked to an IBAction (which is part of the delegate class), while >> the other nib has a mostly identical nib that does not have these >> outlet/actions? >> >> So when I define MyCommonAppDelegate in the nib, it should only have the >> "SparkleUpdate" IBAction in the retail version... So this code really sits >> in MyPrefPaneDelegate... But how do I get IB to realize this? >> >> I am really trying not to have any duplicated code here. > > Easy. > > If you use the superclass idea, have the action methods declared and defined > in the superclass, with empty implementations. The concrete retail subclass > overrides those implementations with what you're actually supposed to do. The > concrete app subclass doesn't care. The retail nib has buttons that trigger > those actions, the app nib doesn't use the actions at all. > > If you go with the protocol idea, it's pretty much the same. Define your > action methods in the protocol, with empty implementations in the app delegate > class and actual useful implementations in the retail delegate class. Again, > the retail nib has buttons that trigger those actions, but the app nib ignores > them. >
So if the superclass has -(IBAction)doSparkleStuff:(id)sender And this supercalss is instantiated in the nib, won't this appear in the nib somewhere even if it does not hook to the action? I can't have it that way (at last if I want to call the methods anything containing "sparkle". T _______________________________________________ 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
