Using the COM interface on a thread withou a message pump

[tri]

Hi there,

I'm having a little difficulty retrieving values from the Sensor object.... well, in some cases. It's a multithreaded app. I'm using the COM interface without ATL (or the ATL headers... by using things like TDxInput::ISensorPtr from the #import generated headers). It's based on the polling example. I call CoInitialize on all threads.

The thread I want to retrieve the sensor and keyboard values from does not have a windows message pump. Everything seems to work fine; except the values (translation and rotation angle) I get are always 0.0... but nothing fails.

When I place exactly same code in the same thread that created the window and dispatches windows messages, it all works fine... but it means a slightly less elegant design on my end.

Is this a know restriction?

I also noticed that I receive message 0xC45C when calling PeekMessage or GetMessage in the message pump (but before dispatching the message) when the 3dconnexion device is moved.

If the COM 3dconnexion code must go on the same thread as the one that created the window, can I rely on this message being sent in future driver versions? This would allow a mostly even-driven scheme without requiring ATL.

According to the windows SDK docs, this message is custom:

The system returns a message identifier in the range 0xC000 through 0xFFFF when an application calls the RegisterWindowMessage function to register a message. The message identifier returned by this function is guaranteed to be unique throughout the system. Use of this function prevents conflicts that can arise if other applications use the same message identifier for different purposes.

What system-independent method would I use to retrieve the exact ID of the message? I presume I need to know the string that RegisterWindowMessage was called with.

One last comment I think I also prefer the C API (a few people have mentioned this) and I hope it continues to be supported. Although it's probably true that the COM interface is more approachable from other languages (Java, VB, etc), it's less platform-independent. With a C interface, exactly the same code could be used from MAC, Windows, Linux etc... all those HRESULTS and CoInitializes are windows specific.

If someone can let me know where do DL the old SDK, that would be appreciated.

Thanks for any help.

--tristan

[mbonk]

Hi there,

The thread I want to retrieve the sensor and keyboard values from does not have a windows message pump. Everything seems to work fine; except the values (translation and rotation angle) I get are always 0.0... but nothing fails.

--tristan

How are you creating the device instance?
I think if you create the device instance and do all the rest of the initialization on the main thread you ought to be able to get the sensor and keyboard values in any thread as long as you retreive the sensor and keybaord objects from that device.

Markus

[mbonk]

Hi there,

I also noticed that I receive message 0xC45C when calling PeekMessage or GetMessage in the message pump (but before dispatching the message) when the 3dconnexion device is moved.

If the COM 3dconnexion code must go on the same thread as the one that created the window, can I rely on this message being sent in future driver versions? This would allow a mostly even-driven scheme without requiring ATL.

According to the windows SDK docs, this message is custom:

The system returns a message identifier in the range 0xC000 through 0xFFFF when an application calls the RegisterWindowMessage function to register a message. The message identifier returned by this function is guaranteed to be unique throughout the system. Use of this function prevents conflicts that can arise if other applications use the same message identifier for different purposes.

What system-independent method would I use to retrieve the exact ID of the message? I presume I need to know the string that RegisterWindowMessage was called with.


--tristan

Relying on the message is not recommended.
In fact, you can rely on the message being removed in the future.

Markus

[tri]

Hi Markus,

Thanks for your helpful feedback. I will not rely on the windows message.

How are you creating the device instance?
I think if you create the device instance and do all the rest of the initialization on the main thread...

I'm creating the device as follows:

Code: Select all

HRESULT result = pDevice.CreateInstance(__uuidof(TDxInput::Device));

where pDevice is declared (and defined) as:

TDxInput::ISimpleDevicePtr pDevice = 0;

Anyways, you seem to be correct. When I create the device from the thread that creates the window, I am able to successfully use the device in my world-update thread...apart from having to be careful about synchronizing the device creation with the different threads, this is certainly enough to keep me happy.

It might still be worth noting this behaviour as an issue for future driver releases since retrieving device input values should probably not have anything to do with what thread the device is created on.

Thanks again.

--tristan

[mbonk]

It might still be worth noting this behaviour as an issue for future driver releases since retrieving device input values should probably not have anything to do with what thread the device is created on.
--tristan

This is definitely something we will look into more deeply. This kind of feedback is very valuable, thank you!

Markus