Oh yeah. I've actually already done that with some other cocoa calls. I forgot. I have deploy sdk = 10.4 and base sdk = 10.5 (will change to 10.6). Thanks, Joel
On Feb 23, 2010, at 4:30 PM, Jean-Daniel Dupas wrote: > 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
