It looks like you are using an older COM API that is no longer in maintenance. It probably does work though.
50741d == c635h.
You can find this ProductID in <3DxWinCore>/Cfg/Base.xml:
Code: Select all
<Device>
<ID>ID_ProductID_C635</ID>
<Name>SpaceMouse Compact</Name>
<VendorID>256f</VendorID>
<ProductID>c635</ProductID>
In general, we don't want you to do anything special when there is, or is not, a device attached when your app starts. This interrupts hot plugging (user attaches a device later). The driver always tells you there is a device attached, a so-called "NotificationOnly" device if nothing else. If a user attaches a real device later, you will be sent an event of that attachment. But, generally, it will just start working. IOW, your code will just start getting events. There isn't anything you need to do to support this. Also, if multiple devices are attached, the default behavior is to fold all those data streams together and you just see more events coming. This only works if you open the connection to the driver.
You can find out which actual devices are attached by responding to the connection events. We don't encourage it.
That describes the raw API behavior. Ultimately, we really don't want you to even know anything about the attached device(s). It makes it difficult for you to support new devices when we release them.
I assume you are using the device type to do some device-specific assignment/UI. We don't encourage that either. We've moved to a model of having the apps export relevant info to the driver and the driver's GUI does all the programming. This provides a consistent interface to users who use multiple applications.
There is a new API/SDK (v4) that removes all knowledge of input devices and just deals with view changes. We recommend that approach if you are rewriting your interface. It insulates your code from future device changes.
With all that said, the Siapp API you were originally using, is still supported. In fact, it is beneath everything built on top. It is, though, somewhat device-specific. Thus, why we encourage developers to move away from it.