• 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: Developing for Tiger and Panther;
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Developing for Tiger and Panther;


  • Subject: Re: Developing for Tiger and Panther;
  • From: glenn andreas <email@hidden>
  • Date: Thu, 28 Jul 2005 10:22:17 -0500


On Jul 28, 2005, at 10:08 AM, Matt Budd (Madentec) wrote:

Hi Ben,

You're right, this is exactly how I did it at first and everything worked. The problem happens when instead of using NSAnimation directly I want to use a subclass of NSAnimation. As per your example:

if( system is less than tiger ) { //can actually test if (NSClassFromString(@"NSAnimation") == nil)
animationClassToUseAtRuntime = [YourAnimationClass class];
} else {
animationClassToUseAtRuntime = NSClassFromString (@"MyOtherAnimatoinClassThatIsNSAnimationSubclass");
}


Even though if I am running on Panther, I never execute the else- condition of that statement, the app still crashes because it have code for my "MyOtherAnimatoinClassThatIsNSAnimationSubclass" class that is a subclass of NSAnimation. So when the runtime tries to +initialize that class, it has to load NSAnimation and can't find it on Panther. Basically I'm not given a chance to test to see if I am on Tiger (i.e. if NSAnimation is a valid class) when the Cocoa runtime +initialize's my subclass.


Right - that's because the linker inserts runtime code that "hooks up" classes, one step of which is to point a class to its superclass. And if the superclass doesn't exist, boom, things go bad (that's where _objc_fatal gets called).


So basically, you can't subclass a class that doesn't exist.

In order to have a subclass of NSAnimation (or other non existent class) you're going to have to do some deep hacking of the runtime:
Declare a dummy class that has the same size as NSAnimation (same ivars will do it)
Make your class a subclass a subclass of that new dummy class.
At run time, repoint your class's superclass to point to NSAnimation instead (and ISTR that you need to do the same for the metaclass).


If you don't feel comfortable doing this sort of thing (and you probably shouldn't), it probably means that this approach isn't something you should be taking.

The "better" solution is to create a loadable bundle for each OS version, and then at startup you can load the correct bundle (one has your pseudo NSAnimation, the other has a subclass of the real NSAnimation - they can even have the same name so that the rest of your code doesn't need to conditionally figure out which to use).


Glenn Andreas email@hidden <http://www.gandreas.com/> wicked fun! quadrium | build, mutate, evolve | images, textures, backgrounds, art

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Developing for Tiger and Panther; (From: Ben Dougall <email@hidden>)
 >Re: Developing for Tiger and Panther; (From: "Matt Budd (Madentec)" <email@hidden>)

  • Prev by Date: Re: [Core Data - Newbie] Creating Reports
  • Next by Date: Re: CoreData and NSCalendarDate/NSDate attributes
  • Previous by thread: Re: Developing for Tiger and Panther;
  • Next by thread: Re: Developing for Tiger and Panther;
  • Index(es):
    • Date
    • Thread