How to start the driver programmatically?

WindowsNT · Post by **WindowsNT** » Sat Oct 17, 2009 1:02 am

I 've noticed that the demos also start the driver if not started already. How do they do that, by simply running the .exe to start the driver ?

I 'd like it if there is a way to do that manually.

Post by **jwick** » Sat Oct 17, 2009 5:22 am

Any 3Dx Win32 API call (Si* & therefore TDxInput) will start the driver if it isn't running. That can be a blessing or a curse. The next driver version will have the driver running all the time, even if no device is attached, so I wouldn't worry about starting it. You don't need the driver for DirectInput.

WindowsNT · Post by **WindowsNT** » Sat Oct 17, 2009 6:05 am

Well that doesn't work with my apps (COM). I need to manually start the driver, or else the interfaces don't work.

Am I missing something ?

WindowsNT · Post by **WindowsNT** » Sat Oct 17, 2009 6:15 am

Edit: The driver starts indeed, but the interface doesn't work. I have to run manually the 'start driver' and then it says that the driver is already running, but only after that the device lights and i am able to use it.

Post by **jwick** » Sat Oct 17, 2009 10:21 am

Why doesn't the interface work? Do you get an error message? What O/S?

WindowsNT · Post by **WindowsNT** » Sat Oct 17, 2009 10:45 am

Windows 7 x64.

I receive 0 as the connected device type (no device connected) and I don't get any events from the device.

After starting the driver manually as I said, my app receives input without restarting.

WindowsNT · Post by **WindowsNT** » Sat Oct 17, 2009 10:46 am

However, the demos do start the interface and the device lights. So it shouldn't be a driver issue. Perhaps the way I am creating the TDx interface ?

WindowsNT · Post by **WindowsNT** » Sat Oct 17, 2009 1:53 pm

Edit: No, the demos don't start it. Cube says 'can't find a 3d controller'.

I have to start it with the 'start driver' first.

Post by **jwick** » Sat Oct 17, 2009 2:17 pm

This could be a problem with Windows 7. I'd have to verify.

Why don't you just allow it to start in the startup folder the way we install it?

WindowsNT · Post by **WindowsNT** » Sat Oct 17, 2009 2:33 pm

That would be an option, but I am not exactly the type of the user that wants applications running when not needed.

Also, now I am testing again, it seems that from your demos, Cube3D can't load the driver, but puzzle.exe and others can.

What are you doing in that one ?
Does the library need a specific COM mode (appartment/multithread?)

Here is my code (error checking stripped)

CoCreateInstance(__uuidof(TDxInput::Device),0,CLSCTX_ALL,__uuidof(TDxInput::ISimpleDevice),&p_SimpleDevice);
p_SimpleDevice->Connect();
long pV = 0;
p_SimpleDevice->get_Type(&pV);

pV is 0.

Post by **jwick** » Sat Oct 17, 2009 7:40 pm

Cube doesn't use the 3Dx Win32 API. Puzzle & jet do. That's why it doesn't start the driver.

I'm not much help with the COM code. I suggest you follow the sample code quite religiously. Does the sample code start the driver?

As I mentioned, starting and stopping the driver on your whim won't be an option in the next release.

WindowsNT · Post by **WindowsNT** » Sun Oct 18, 2009 12:55 am

Does any of the provided samples in the SDK use the win32 interface so I can see what I am missing ?

Edit: i got the Win32 SDK. Should I use that instead and the Si* functions ? It seems to me that the COM interface is more appropriate (because if the app is statically linked it won't run when the SDK is missing) but the Win32 SDK provides more functions.

I think that you should simply create another interface like I3DConnexion* which provides all these functions the win32 SDK provides as virtual members so they are also usable from the proper COM interface.

Michael.

Post by **jwick** » Sun Oct 18, 2009 9:29 am

Often times developers find the Si* functions more straightforward to work with.

Yes, there is much more functionality in the Win32 SDK (Si*). We have discussed incorporating some of that functionality into the COM interface. The COM interface is meant to be a simplified interface. Of course, it uses COM. The jury is still out on how many people find COM simple to use. We don't have any hard data.

Other options? The native MS APIs: Raw Input, DirectInput, HID.

WindowsNT · Post by **WindowsNT** » Sun Oct 18, 2009 10:51 am

Well using the Win32 SDK requires to link against the DLLs. This creates additional code because if you just link against the DLL the application doesn't run when the DLL is missing.

Using the DirectInput interface is mostly for game controllers which always return to 0,0 when left (joysticks), so it can't easily be used as an abstraction for all joysticks and 3DConnexion devices because an application that can use a joystick expects different behaviour, not the behaviour of a 3D Device.

Using raw input or hid requires the user to interpret the returned values.

In my opinion, COM is the best. If you take a look at newest Windows 7 technologies I am working with (Ribbon, Sensors,Location Platform etc), all these are COM-based. The question is why some stuff is left outside it.
You don't put in jeopardy the simplicity. Just create another interface, I3DConnexion2 which will export all available functions.

By the way the 3DConnexion device also needs a sensor interface for Windows 7 and I will try to make a sensor driver that can map a 3DConnexion device into a sensor.

Post by **jwick** » Sun Oct 18, 2009 4:59 pm

Well using the Win32 SDK requires to link against the DLLs. This creates additional code because if you just link against the DLL the application doesn't run when the DLL is missing.

You link against our static lib. If installed, that static lib finds and loads our DLLs. If they are not installed, it's a NOP.

Using the DirectInput interface is mostly for game controllers which always return to 0,0 when left (joysticks), so it can't easily be used as an abstraction for all joysticks and 3DConnexion devices because an application that can use a joystick expects different behaviour, not the behaviour of a 3D Device.

Using raw input or hid requires the user to interpret the returned values.

All MS APIs can return the same data in the same format that our COM and/or Win32 SDK returns. See our posted sample code.

In my opinion, COM is the best. If you take a look at newest Windows 7 technologies I am working with (Ribbon, Sensors,Location Platform etc), all these are COM-based. The question is why some stuff is left outside it.
You don't put in jeopardy the simplicity. Just create another interface, I3DConnexion2 which will export all available functions.

I'll bring that up with the powers that be.

By the way the 3DConnexion device also needs a sensor interface for Windows 7 and I will try to make a sensor driver that can map a 3DConnexion device into a sensor.

Yes, that does look interesting.