On Mar 23, 2012, at 11:05 AM, Fritz Anderson wrote: > You're trying to use the NSTextFinder object on Lion, from an app whose base > SDK is Tiger. Xcode is sensitive to what the base SDK is.
I don't think that's the issue because NSTextView, when called from within my app, uses instances of NSTextFinder to perform the find/replace actions. > * Symbols exclusive to a later SDK than then base shouldn't be compilable or > linkable at all. I'm unsure how you got past this barrier. This leads me to > believe that either you've instituted a gigantic hack, or your description of > your situation is inaccurate. Care to elaborate? To compile, I created a subset of the NSTextFinder header with methods pulled from 10.7 SDK version. There's no issue with linking because dyld finds NSTextFinder at load time, and the methods dispatched dynamically, not through a static offset from 'self'. > * To preserve backward compatibility, when OS version N detects that an > application has been linked against SDK version (M < N), it does not provide > bug-fixes or other changes that were instituted after version M. I'm aware of that issue, but for the reason I stated above, I don't believe it's part of the problem. > Even if you managed somehow to add NSTextFinder to your headers and > libraries, Cocoa would not provide behavior that NSTextFinder may rely on. The instances of NSTextView I use seem to be getting everything they need. They show the find panel when asked. Have you used NSTextFinder with a client other than NSTextView and NSScrollerView? _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
