Re: Check for 10.2 incompatibilities in XCode
Re: Check for 10.2 incompatibilities in XCode
- Subject: Re: Check for 10.2 incompatibilities in XCode
- From: "Laurent Daudelin" <email@hidden>
- Date: Tue, 24 Feb 2004 13:27:00 -0500
On 24/02/04 12:50, "Roberto Sobachi" <email@hidden> wrote:
>
How can I find Mac OS X 10.2 incompatibilities in my code?
>
>
Not in Interface Builder.
>
You can do a "Get Info" on your project (select your project file in the
left column, then do "Get Info" from the "Project" menu. Select
"MacOSX10.2.7" from the cross-develop using target SDK popup menu. Do a
clean, then recompile.
However, there is one flaw with this approach. Suppose that one of your
object implements a delegation method that was introduced in 10.3. This
method should not cause any harm if your app is run on a 10.2 system. For
some reason, even in 10.3, that delegation method won't be called if you
build your app against the 10.2.7 SDK.
So, what I ended up doing was to select the 10.3 SDK. Then, when I'm done
with my changes to the code, I add a header file to the target, using the
"Prefix header" in the build settings of the target. This header gets
included with every file I compile. The content of that header is as follow:
#import <Foundation/NSObject.h>
#include <AvailabilityMacros.h>
#ifdef MAC_OS_X_VERSION_MAX_ALLOWED
#undef MAC_OS_X_VERSION_MAX_ALLOWED
#endif
#define MAC_OS_X_VERSION_MAX_ALLOWED MAC_OS_X_VERSION_10_2
Then, every file in your code that uses something introduced with 10.3 will
be flagged as an error. Again, this is not a perfect solution as some
included Apple headers will obviously call some 10.3 methods (since you
selected the 10.3 SDK) and you'll get a bunch of warnings from those headers
using unknown types or calling unknown methods.
What you do next is up to you. If one of my class is explicitly calling a
10.3 method, then I check to see if the receiving object responds to that
selector using 'respondsToSelector:'. If it does, then to avoid getting a
warning, I call the method using one of the 3 flavors of 'performSelector:'.
If the warning is generated from an included header on which you don't have
any control, then you can fake the compiler in believing that the unknown
reference does indeed exist. In my compatibility header, I declare some
types that were introduced in 10.3 like:
typedef enum _NSAnimationEffect {
// The default effect used to indicate removal of an item from a
collection,
// such as toolbar (indicates removal, without destroying the underlying
data).
NSAnimationEffectDisappearingItemDefault = 0,
// An effect showing a puff of smoke.
NSAnimationEffectPoof = 10
} NSAnimationEffect;
These declarations come from the relevant 10.3 header. I know that these are
safe since they won't be called if my app is running on a 10.2 system.
That's the best way I found to gain access to new features in 10.3 while
remaining compatible with 10.2.
-Laurent.
--
========================================================================
Laurent Daudelin Developer, Multifamily, ESO, Fannie Mae
mailto:email@hidden Washington, DC, USA
************************ Usual disclaimers apply ***********************
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.