On Dec 18, 10:03 am, Michael Ash <m...@[EMAIL PROTECTED]
> wrote:
> outpaddling <jba...@[EMAIL PROTECTED]
> wrote:
> > I tried just calling CFRunLoopRun() with the default env, but the
> > handler doesn't fire. Some other docs I found suggested that I need
> > to add a source using CFRunLoopAddSource(), but I haven't been able to
> > figure out how as yet.
>
> The way this stuff *usually* works is, you create the object, set up a
> callback, then there's some function to create a CFRunLoopSourceRef from
> the thing you're working with. For example, a CFMessage****t has a
function
> called CFMessage****tCreateRunLoopSource which returns a
CFRunLoopSourceRef
> and you can then add that to the CFRunLoop.
>
> I don't know if that's really how it works with Bluetooth, and I don't
> know what the function would be if so, but I guess that's the sort of
> thing to look for.
>
> --
> Michael Ash
> Rogue Amoeba Software
I actually already got this far, and found in the Xcode docs:
CFMessage****tCreateRunLoopSource
Creates a CFRunLoopSource object for a CFMessage****t object.
CFRunLoopSourceRef CFMessage****tCreateRunLoopSource (
CFAllocatorRef allocator,
CFMessage****tRef ms,
CFIndex order
);
Problem is, I don't know where to get the CFMessage****tRef from. I
browsed the framework docs, and found some possibilities, each with
additional parameters that I didn't know where to get. At this point
I just had to chuckle. The time required to explore every possible
branch of this trail grows geometrically with each additional layer,
and I'm not even certain that CFMEssage****t is the right path to
follow. It's clear that I would need to know a lot about Carbon/Cocoa
programming, including several core frameworks, in order to solve this
one on my own, and I just don't have the time, so I have to hope I can
find an analogous code example. It would have been so simple if Apple
would have just let us do synchronous reads. Oh well...
Thanks for the ideas,
Jason
|
