You don't have to build a separate version. Just test for method availability
at runtime:
if ([NSEvent respondsToSelector:@selector(pressedMouseButtons)])
return [NSEvent pressedMouseButtons];
else
// do it the old way.
Le 23 févr. 2010 à 23:18, Joel May a écrit :
> Hey Eric,
>
> This is very helpful. I'll take a look at [NSEvent pressedMouseButtons]. I
> still have to support tiger and leopard, but I'll build a separate snow
> leopard version and #ifdef that call in there.
>
> I've had the heebie-jeebies about including the Carbon framework in my
> application. But I'm cool with it now.
>
> Thanks,
> Joel
>
>
>
> On Feb 23, 2010, at 1:15 AM, Eric Schlegel wrote:
>
>>
>> On Feb 22, 2010, at 11:53 AM, Joel May wrote:
>>
>>> I would like to create a thread (NSThread) with a bumped-up priority and
>>> poll the mouse and keyboard the same way I did in the carbon version. I'd
>>> like to use the cocoa equivalents of GetButton() and GetKeys() but I can't
>>> find them.
>>
>> GetButton() [by which I think you actually mean Button()] - the Cocoa
>> equivalent is +[NSEvent pressedMouseButtons], available in 10.6 and later
>> GetKeys() - I don't believe there is currently a Cocoa or CoreGraphics
>> equivalent (but could be wrong!). It's perfectly fine to continue using
>> GetKeys().
>>
>>> Am I safe using these api's. Are we supposed to not use them?
>>
>> You are safe using these APIs. They are still supported. We recommend that
>> you use Cocoa equivalents when available - so you could use +[NSEvent
>> pressedMouseButtons] on 10.6 and later, and Button() on 10.5 and earlier.
>>
>>> Will they go away in 10.7?
>>
>> No, because that would break many existing applications, and we place a high
>> priority on not breaking existing applications.
>>
>>> Why do I read everywhere that carbon is dead and high level toolkit is
>>> dead?
>>
>> Because many people are misinformed. Apple no longer recommends Carbon for
>> new application development - Cocoa is recommended for all new development -
>> but Carbon is not being removed from the OS either, because that would break
>> existing applications. The High Level Toolbox APIs will continue to be
>> supported for 32-bit apps and some parts of HLTB will also still be
>> supported for 64-bit in cases where there is no other 64-bit equivalent.
>>
>>> If High Level Toolkit is ok, then why doesn't it appear in the docs. If I
>>> search the Mac OS X Reference Library, it does not get the same treatment
>>> that the cocoa api gets.
>>
>> You'd have to ask Apple Developer Relations about that. I'm just a grunt
>> engineer. :)
>>
>> -eric
>>
>
> _______________________________________________
>
> 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/devlists%40shadowlab.org
>
> This email sent to devli...@shadowlab.org
-- Jean-Daniel
_______________________________________________
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 arch...@mail-archive.com
