Nick, Thanks for clarifying. I've been uncomfortable with using Carbon. My guts are more settled now.
Question about NSThread seeing how GetKeys(), etc. are not thread safe: If I increase the priority of the main thread, then move the view draw cgcontext updates to a lower priority thread, is that a good idea? Will increasing the priority of the main thread reduce latency for getting the keypress and mouse inputs? Does the OS actually honor this request? Can I take the drawRect requests and pass the rectangle to the lower thread and update the view there? Is this crazy? Non-thread safety of GetKeys() and Buttons(): If I call these in the wrong thread, can they crash the application? Or is the damage limited to erroneous results? Of course, we don't know and we should be good and not do it. But I might get desperate. Thanks huge for your help. Joel On Feb 23, 2010, at 1:19 AM, Nick Zitzmann wrote: > > On Feb 22, 2010, at 12:53 PM, 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. > > There aren't any. GetKeys() still works fine, though it has some annoying > differences depending on the target CPU architecture. Also, you need to do > this on the main thread, since neither GetKeys() nor Cocoa events are > thread-safe. > >> The Carbon64BitGuide.pdf explains how the carbon api's have been updated for >> 64 bit. But I thought carbon was dead in 64 bit and Snow Leopard. What is >> the deal? > > No, Carbon is not dead. The only parts of Carbon that are dead are the > drawing components of HIToolbox, along with some legacy stuff like ATSUI and > FSSpec. GetKeys() is one of the survivors. > >> Am I safe using these api's. > > Yes, unless they have been deprecated. GetKeys() has not been deprecated. > >> Are we supposed to not use them? > > No, but polling is something you probably shouldn't do without a good reason. > >> Will they go away in 10.7? > > Highly unlikely. > >> Why do I read everywhere that carbon is dead and high level toolkit is dead? >> > > Because at least one influential news source ran an incorrect story a number > of years ago that Carbon wasn't being updated for 64-bit at all, which is not > true, but that hasn't stopped people from believing it. > >> 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. The only place I see the High Level Toolkit is in >> the Carbon64BitGuide.pdf and the header files and some cruddy api update >> doc. > > I don't know why a lot of the Carbon documentation was taken out of Snow > Leopard. I wouldn't look too far into that, though. The folder manager > documentation is also MIA but functions like FSFindFolder() still works fine > and are completely supported. > >> Is there a way to poll the state of the hardware using cocoa api's instead >> of the carbon api's? > > No. The Cocoa event system does not act until something happens. Don't be > afraid of using Carbon in a Cocoa application. Sometimes it's the only way to > do something. > > Nick Zitzmann > <http://www.chronosnet.com/> > > > _______________________________________________ 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
