David,
you're thinking in terms of wrapping functions, not wrapping objects.
Use the USB notification you receive when the device is plugged in to create
an object which represents the device, and to register for removals of that
device (see the USB private data sample). When your device abstraction is
created, create and initialize the USB interfaces.
Now you read and write the device abstraction you created. All knowledge of
USB, pipes, interfaces etc. are inside that device abstraction.
When you quit the application, destroy your device object, which should
close and dispose of the USB interface, and remove its device removal
notification.
If the device is removed unexpectedly, commands-in-progress will be returned
with an error, and subsequent commands will be immediately rejected because
the USB interface (still extant) has no corresponding physical device. As
long as you have the IOUSBInterfaceInterface open it won't be released, so
it is always okay to talk to it, even when the physical device has been
unplugged.
Some time after the device is physically unplugged you will receive an
asynchronous device removed notification. You can use this to gracefully
dispose of your own device abstraction.
The above discussion is not Cocoa-specific, you could create a device
abstraction in any language; a language which directly supports objects
makes life considerably easier.
hth, Stuart
on 2/18/05 12:10 PM, email@hidden at
email@hidden wrote:
> Message: 4
> Date: Fri, 18 Feb 2005 10:15:18 -0800
> From: David Sopchak <email@hidden>
> Subject: Good form for opening/writing/closing
> To: email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> 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
