Slow initialization in non-ATL code (CreateInstance)

[andek]

Hi,

After reading various posts on this forum, I decided to use the non-ATL approach to support the SpaceNavigator from my C++ application. When the device is connected, everything works fine.

On some computers, where the SpaceNavigator is not currently connected, the initialization hangs for about 5 seconds - obviously an annoying delay for our users. I have narrowed it down to the CreateInstance method which is where the 5 second delay happens. This is a snippet from my code:

Code: Select all

// Initialize COM
HRESULT hr = CoInitializeEx(0, COINIT_APARTMENTTHREADED);
if (!SUCCEEDED(hr))
  return;

// Create the device object
ISimpleDevicePtr device;
hr = device.CreateInstance(__uuidof(Device)); // THIS TAKES ABOUT 5 SECONDS!
if (!SUCCEEDED(hr))
  return;

// Get the interfaces to the sensor and the keyboard
sensor_ = device->Sensor;

keyboard_ = device->Keyboard;

// Associate a configuration with this device (not sure what this does)
device->LoadPreferences(bstr_t("Remo 3D"));

// Connect to the driver
device->Connect();

Does anyone have a clue why this is happening and what I can do to prevent it? Note that the code runs through completely even if the device is not connected, so CreateInstance is apparently successful but slow in this case.

Regards,
Andreas Ekstrand

[jwick]

The CreateInstance tries to start the driver, if it is installed. If the driver is not installed there should be no delay. If the driver is installed, the driver will try to find a device. That can take time.

There are three options:

1) Your users can uninstall the driver when they uninstall the hardware. (Recommended)
2) You can call FindWindow to find out if the driver is running. If not, there probably isn't a device and you should not make any TDxInput calls and experience the delay. This would deactivate the driver's autostart capability.
3) Wait for the next version of the driver, which will run all the time and not have a delay checking for devices.

Jim
3Dx Software Development

[andek]

Thanks for the answer.

Actually, I noticed that the driver on a computer showing this problem was quite old, so I tried installing the new 3.8.1 driver. Since then, I can't reproduce the problem, so could it be that it's already fixed in that version?

/Andreas

[jwick]

Some changes were made a very long time ago to help but not eliminate this issue. If the old driver supported serial devices, it would take quite a long time to check all the serial ports.

I'm glad it is working ok now.

Let us know if there is anything else we can help with.

[andek]

Thank you!