Comments on: Remote Control Wrapper 2.0 http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/ hot bits and bytes Sun, 18 May 2008 10:49:26 +0000 http://wordpress.org/?v=2.2.1 By: vinay http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-11159 vinay Sat, 08 Mar 2008 13:21:56 +0000 http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-11159 <p>Thanks for publishing this. It will be very useful to my application.</p> Thanks for publishing this. It will be very useful to my application.

]]>
By: martin http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-9295 martin Wed, 30 Jan 2008 17:52:19 +0000 http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-9295 <p>Hi Jim,</p> <p>I'm a Cocoa guy and try to avoid Carbon if possible :-) Let's see if I can help.</p> <p>Objective-C is a object orientated language. These means you are executing functions on objects. The Carbon based APIs are in some sense object orientated as well. The main difference is that you are using a number of functions where you provide the data structure in the first parameter.</p> <p>Let's see how some Cocoa code converts to Carbon code: // allocate an Array - there are two function calls: alloc and init here NSMutableArray* a = [[NSMutableArray alloc] init]; // allocate a string object - the next line defines a string object (compareable to CFStringRef) NSString* value = @"some string"; // here we call the function addObject [a addObject: @"some string"];</p> <p>In Carbon it would look like this: CFMutableArrayRef a = CFArrayCreateMutable(NULL, 0, NULL); CFStringRef value = CFSTR("some string"); CFArrayAppendValue(a, value);</p> <p>So it's pretty straight forward to convert Cocoa code to Carbon code as long as there are matching methods in both frameworks. You can even mix Carbon and Cocoa code pretty easy. </p> <p><em>NSArray is “toll-free bridged” with its Core Foundation counterpart, CFArray. What this means is that the Core Foundation type is interchangeable in function or method calls with the bridged Foundation object, providing you cast one type to the other. Therefore, in an API where you see an NSArray * parameter, you can pass in a CFArrayRef, and in an API where you see a CFArrayRef parameter, you can pass in an NSArray instance. This arrangement also applies to your concrete subclasses of NSArray. See Carbon-Cocoa Integration Guide for more information on toll-free bridging.</em></p> <p>hope this helps.</p> Hi Jim,

I’m a Cocoa guy and try to avoid Carbon if possible :-) Let’s see if I can help.

Objective-C is a object orientated language. These means you are executing functions on objects. The Carbon based APIs are in some sense object orientated as well. The main difference is that you are using a number of functions where you provide the data structure in the first parameter.

Let’s see how some Cocoa code converts to Carbon code:
// allocate an Array - there are two function calls: alloc and init here
NSMutableArray* a = [[NSMutableArray alloc] init];
// allocate a string object - the next line defines a string object (compareable to CFStringRef)
NSString* value = @”some string”;
// here we call the function addObject
[a addObject: @”some string”];

In Carbon it would look like this:
CFMutableArrayRef a = CFArrayCreateMutable(NULL, 0, NULL);
CFStringRef value = CFSTR(”some string”);
CFArrayAppendValue(a, value);

So it’s pretty straight forward to convert Cocoa code to Carbon code as long as there are matching methods in both frameworks.
You can even mix Carbon and Cocoa code pretty easy.

NSArray is “toll-free bridged” with its Core Foundation counterpart, CFArray. What this means is that the Core Foundation type is interchangeable in function or method calls with the bridged Foundation object, providing you cast one type to the other. Therefore, in an API where you see an NSArray * parameter, you can pass in a CFArrayRef, and in an API where you see a CFArrayRef parameter, you can pass in an NSArray instance. This arrangement also applies to your concrete subclasses of NSArray. See Carbon-Cocoa Integration Guide for more information on toll-free bridging.

hope this helps.

]]>
By: Jim Crompton http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-9239 Jim Crompton Tue, 29 Jan 2008 13:35:22 +0000 http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-9239 <p>"For interacting with the device the IOKit framework is being used. This a C based API. So when you extract the code from the Objective-C classes you can use it in Carbon based applications as well. You have to translate the NSArray/NS… to CFArray/CF… code as well of course."</p> <p>I'd really, really, really like to be able to understand that - but I'm a pure Carbon head and don't do Cocoa. Any chance of a quick Carbon guide?</p> “For interacting with the device the IOKit framework is being used. This a C based API. So when you extract the code from the Objective-C classes you can use it in Carbon based applications as well. You have to translate the NSArray/NS… to CFArray/CF… code as well of course.”

I’d really, really, really like to be able to understand that - but I’m a pure Carbon head and don’t do Cocoa.
Any chance of a quick Carbon guide?

]]>
By: martin http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-8470 martin Mon, 31 Dec 2007 13:28:15 +0000 http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-8470 <p>There is no such option in the code yet. But it's easy to do as you get a separate event for button press and button release. So you can start executing a method periodically when the button is pressed, and stop it when the button is being released. e.g.: in Sofa Control I'm doing it like this [self performSelector:@selector(buttonHoldTimer:) withObject:self afterDelay:0.1];</p> There is no such option in the code yet. But it’s easy to do as you get a separate event for button press and button release.
So you can start executing a method periodically when the button is pressed, and stop it when the button is being released.
e.g.: in Sofa Control I’m doing it like this
[self performSelector:@selector(buttonHoldTimer:) withObject:self afterDelay:0.1];

]]>
By: David M. Cotter http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-8396 David M. Cotter Fri, 28 Dec 2007 02:38:16 +0000 http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-8396 <p>is there a way to get repeated press events, instead of a single hold event?</p> <p>eg: when i hold the vol+ key, i want to get a stream of vol+ key events, at the same pace as the keyboard "autoKey" events.</p> is there a way to get repeated press events, instead of a single hold event?

eg: when i hold the vol+ key, i want to get a stream of vol+ key events, at the same pace as the keyboard “autoKey” events.

]]>
By: Nazz http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-7204 Nazz Sat, 03 Nov 2007 20:42:11 +0000 http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-7204 <p>I take that back, the old code was running simultaneously. The new code is working fine on Leopard. Woohoo!</p> I take that back, the old code was running simultaneously. The new code is working fine on Leopard. Woohoo!

]]>
By: Nazz http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-7203 Nazz Sat, 03 Nov 2007 20:40:53 +0000 http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-7203 <p>I used to use the old AppRemote code on Tiger and it worked fine. It doesn't work on Leopard though. I downloaded the new code you have here too and it doesn't work under Leopard either. </p> <p>I've built the RemoteControlWrapper and launched the app it will not recognize the Apple Remote after I click on Listen to Remote. No other apps are running and the remote works fine when using iTunes, etc. No errors are reported in the Console log. I'm on the first generation 24" iMac. Any ideas?</p> I used to use the old AppRemote code on Tiger and it worked fine. It doesn’t work on Leopard though. I downloaded the new code you have here too and it doesn’t work under Leopard either.

I’ve built the RemoteControlWrapper and launched the app it will not recognize the Apple Remote after I click on Listen to Remote. No other apps are running and the remote works fine when using iTunes, etc. No errors are reported in the Console log. I’m on the first generation 24″ iMac. Any ideas?

]]>
By: martin http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-7050 martin Sun, 28 Oct 2007 14:38:59 +0000 http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-7050 <p>For interacting with the device the IOKit framework is being used. This a C based API. So when you extract the code from the Objective-C classes you can use it in Carbon based applications as well. You have to translate the NSArray/NS... to CFArray/CF... code as well of course.</p> For interacting with the device the IOKit framework is being used. This a C based API. So when you extract the code from the Objective-C classes you can use it in Carbon based applications as well. You have to translate the NSArray/NS… to CFArray/CF… code as well of course.

]]>
By: Thorsten http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-6957 Thorsten Fri, 26 Oct 2007 11:42:36 +0000 http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-6957 <p>Can I access the wrapper from Carbon, too?</p> Can I access the wrapper from Carbon, too?

]]>
By: Chris http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-5549 Chris Fri, 24 Aug 2007 14:19:35 +0000 http://www.martinkahr.com/2007/07/26/remote-control-wrapper-20/#comment-5549 <p>Thanks! As the trackback above says, I'm already using it in my own projects. It's a very nice bit of code that you should be very proud of. I had no problems getting any of it to work.</p> Thanks! As the trackback above says, I’m already using it in my own projects. It’s a very nice bit of code that you should be very proud of. I had no problems getting any of it to work.

]]>