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 (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 [EMAIL PROTECTED]

Reply via email to