When your program first runs, install the notifications and loop
through the returned iterator. When your callbacks fire, open or close
your device as necessary, updating your UI to reflect the state of the
device. When your app quits, simply disconnect from the device if it is
plugged in.
Important Notes:
1) Read the header file documentation for
IOServiceAddMatchingNotification()
2) IOServiceAddMatchingNotification() eats one of references for the
matching CFDictionary that you pass in. Plan for this, it has caused
more than one crash for me.
3) The returned iterator is already primed. Pass it to your callback
functions and walk the iterator until it is empty to arm it! This has
the additional bonus that all devices already attached that matched the
dictionary for kIOMatchedNotification, will be listed. You can use this
instead of having additional startup code to search for your device.
As far as the style of when to open and close the device, that depends
on your apps situation. If you only need to send/get data in response
to a rare user event, then the open and close overhead is not bad. This
is particularly so, if your app must deal with the potential of
controlling multiple devices and the user must decide which device to
modify at the moment. Using the Matching Notifications above, you can
easily keep track of what devices are currently attached. So you don't
have the overhead of searching for your device and not knowing if it is
there.
If, on the other hand, your app needs to constantly talk to the device,
(even if it's only every 5 seconds), then your probably better off
opening the device as soon as you can and leave it open until your app
quits (or the user disconnects the device).
hth,
-raleigh
On Feb 18, 2005, at 10:15 AM, David Sopchak wrote:
Hi all,
I was able to modify USBSimpleExample to get it to talk to a LabJack
UE9 data acquisition device. Once I get the device, interface and
pipes set up, I would like to be able to just read and write to the
Labjack, then close up shop when I'm done. USBSimpleExample gets
things set up with a handleDevice function calling a handleInterface
function calling a handlePipes function, at which point I'm all set to
write and read to the LabJack.
All I really want to do at this point is write a writeRead function so
I can access the LabJack from some Cocoa classes. I suppose I could
just put the low level device/interface/pipe setup in the main.m
before calling NSApplication and then close stuff out after
NSApplication is done, but I bet if the LabJack is unplugged while
NSApplication is running things will barf. This would probably work
but the unplug thing bothers me. The other way would be to put Cocoa
wrappers around and create open and close methods for
device/interface/pipe stuff so I could call all this stuff from higher
up. Somewhere in between, I'm wondering, is a one stop shop where the
writeRead is one monolithic fxn where the device is found, interface
and pipes are opened, write and read are performed,everything is
closed up and the device released. The main downside to this I suspect
is it carries unnecessary overhead of open/close each time. Maybe not
a big deal, though.
This is a style question, I guess, but before I go wasting my time on
a bad approach, I was wondering what you folks thought.
Thanks,
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/usb/email@hidden
This email sent to email@hidden
-----------------------------------------------------------------------
Raleigh Ledet email@hidden
Wacom Technology Corp. Towards the Harmonious
Mac Software Engineer Development Between
Human and Computer.
------------------------------------------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/usb/email@hidden
