Thus far, we have been unable to replicate any freezing during an operation if the XEM is detached. PipeTest, for example, doesn’t gracefully die because it isn’t written to handle detachment, but it also doesn’t hang. Our FrontPanel application, however, is designed to gracefully handle detachment. (but it also doesn’t perform any pipe transactions)
The recommended way to handle detachment under Windows is for your application to listen for the WM_DEVICECHANGE event. This event is sent any time a USB device has been added or removed from the system. When you receive this event, your application must rescan the devices to see if the XEM serial number you were talking to is still available.
We presently use the Cypress driver as our underlying device driver. Unfortunately, that puts us at their mercy and reliant on their programming prowess. I apologize if you lost any data when their driver crashed.
As with many programming issues, the “right way” is often much more complicated than the simple examples provided. Capturing the WM_DEVICECHANGE is one thing FrontPanel does that our samples do not do. We avoided this complexity in our samples because, in some cases, it would double their size. Likewise, many of our applications written for clients use multi-threaded and mutexed access to the device which is necessary in some cases. Again, for some programmers this is simply too complicated to follow.
Done right, the PipeTest sample would include multi-threaded access because it can perform long operations with the device that otherwise clog up the Windows event loop. It would also process the WM_DEVICECHANGE. These are programming practices more in-line with good operating system programming and less with talking with our API, so we decided to leave them out – it’s more Microsoft’s charge to show examples of good OS programming.
If there is interest, we would consider adding a WM_DEVICECHANGE processor to a sample. It would probably be better suited to a new sample, but I’m not sure. Any suggestions?