Re: Using deprecated methods
Re: Using deprecated methods
- Subject: Re: Using deprecated methods
- From: Charles Srstka <email@hidden>
- Date: Sat, 5 Jul 2008 22:04:36 -0500
On Jul 5, 2008, at 10:43 AM, Uli Kusterer wrote:
On 05.07.2008, at 15:17, David Duncan wrote:
To handle a case like this, you are going to have to create a
bundle that you link against the 10.5 SDK and only load there. This
bundle will contain your NSViewController subclass and allow you to
conditionally call -setAccessoryView: on 10.4 and -
addAccessoryViewController: on 10.5. This is a general pattern that
you can use when you want to provide alternate functionality where
it is a requirement to subclass and that subclass only exists on a
newer version of the OS.
Or rather, you'll want to do this in a more OO approach, i.e.
abstract your custom print panel stuff away into a class. The base
class is linked into your app, and the loadable bundles implement
subclasses of these. Your app simply uses these classes, and they
take care of using view controllers etc. as needed.
You'd just load the appropriate bundle and instantiate its main
class, then hand it the appropriate views or whatever makes sense.
Alternately, you could also implement your own version of
NSViewController and the viewcontroller-based accessory view
methods, and just load them on 10.4 to provide backwards
compatibility, while your code can effectively assume it always uses
the 10.5 APIs.
I don't know how actually advisable this would be, but if your
subclass can work decently well with or without being a subclass of
NSViewController, you might be able to set the superclass to something
like NSObject and then do something like this in the implementation:
#import <objc/runtime.h>
+ (void)load {
struct objc_class *class = (struct objc_class *)[self class];
Class superclass = NSClassFromString(@"NSViewController");
if(superclass != NULL) {
class->super_class = superclass;
}
}
On Leopard, this would end up swapping the class's superclass to
NSViewController, whereas on Tiger superclass would be NULL and you'd
still be a subclass of NSObject. Your object would of course need to
be able to handle both situations.
Gotta love Objective-C. However, the disclaimer is that I've never
actually done something so drastic as swapping a superclass in my own
code, so I don't know if this will have any evil and/or unexpected
side effects, nor whether this is actually a good thing to be doing or
not.
Charles
_______________________________________________
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