TDxInput does not respond to input

[KMeissner]

Support,

We are small software company which integrates Space Orbs and Space Explorer support into our 3D terrain viewer product. We have several thousand fielded customers, many of whom use the Space Orb as a 3d mouse.

In fact we frequently redistribute 3dconnexion hardware with licensed copies of our products.

In the latest build of the 3dConnexion drivers we have been experiencing a lot of instability.


Use use the 3dxsrv.exe driver to get 3d mouse input and connect to it via the COM interface in TDxInput

However in some cases the user may have choose not to autostart 3dxsrv.exe or may have stopped it manually.

So when our application launches, we look at the process list and check if 3dxsrv is running.
If its is not in the process list, invoke a shell command and create the the process using

3dxsrv.exe -quiet -hideGUI

We also include the latest 3dConnexion drivers in our installers and install it.
But we have noticed a recent change in behavior in the 3dxsrv.
In older versions of the driver we could invoke the 3dxsrv and immediately connect through COM.

But when we upgraded to the newest drivers recently we started getting bug reports that Space Explorer was unresponsive. The was weird since we could stop our app and see the orb working with the demo 3d apps like puzzle that comes with the 3d connexion installer. The driver was running and our app thought it was connected to the input through COM but no actual input was received by our app when the user twiddled the 3d mouse.

Restarting our app and the orb would work as expected. ...
Confusing?!

We investigated and traced it back to the case where our app needed to manually create the 3dxsrv process.
For various good reasons some users opted to not autostart the 3dxsrv

There was no errors in our logs or in any of the return codes from COM when we connected to TDxInput
Finally after much trial and error we found that if we just inserted
::Sleep(2000); // miliseconds
between starting the driver service and connecting it to it through COM then we would receive the input.

needless to say this is pretty hacky.

First of all if there was an error when we connected it should have raise some sort of return code so we could have logged and handled the issues.

Second is 2 seconds enough? How do we know that some slow machines wont need 3 seconds?
How long are we supposed to wait for the driver to be 'ready' there is no indication provided by the driver to the app.

Third this code path worked fine in our app until we upgraded to the latest drivers from 3dconnexion.
It cost us a lot of time and effort to find that we needed to Sleep()
It seems really fragile. Are there other issues we are not aware of in the drivers?

Fourth - there is some sort of version issue with the drivers.
We can tell the drive has changes because the files are different sizes.
But we when we look at the version numbers in the registry they have the same version numbers.

Karl

[jwick]

Are you using COM for a particular reason? We have a different API that will take care of starting the driver for you.

[KMeissner]

We have C++ app that needs to connect to the driver.
When we wrote the hooks a few years ago, COM seemed like the recommended solution.
COM has worked for us for the last few years.
If there is a well documented API that is recommended we can look at migrating in a future version of our app?
Aside from this current issue that just started, is there pro or cons for migrating?
Can you post a link?

[jwick]

You should use the 3DxWare SDK for a C++ program. This is in fact an older very simple C/C++ API but it is kept up-to-date. Many additions have been made for 3DxWare 10, such as plug-n-play and multiple device support. This API is underneath the COM server, but the COM server does not expose everything this API does.

If you have signed up as a 3Dx developer, then you should have access to this through the SDK page. Let me know if you can't find it (sometimes we do have issues with the web pages).

SpaceOrb? Seriously?

[KMeissner]

"SpaceOrb? Seriously?"
nope I got the product names mixed up. We use mostly Space Explorer.

We will look into 3DxWare SDK in a future version. is there a page listing the pro and cons of the various API choices?

For the current issue, we are close to a ship date so have to make what we have work. Is there anything better then Sleep(2000)?

I am looking some thing like
while(!is3dxReady())
Sleep(100);

but there not seem to be any easy way to check if it ready or not with the COM api.

[jwick]

We usually look for the driver's message window. It only exists when the driver is running.

if (FindWindow (_T("SpaceWare Driver Class"), NULL)) == NULL)
{
// driver not running, start it.

... (Call SiInitialize to start it to insulate you from the driver implementation.
For example, the name of the executable changes in 3DxWare 10.)
}