0

I currently am using asynchronous callback to get the motion data through Window's Sensor API. For now I want to test the functionalities through a Windows 10 Console application (NOT a Windows Application). To simplify things, I am currently having the exact same problem as How to cause my C++ program to wait for sensor events for ever and not terminate, where

while(true) { hr = sensor->SetEventSink(pMyEvents); } fires the event and I get consistent data, but the proper usage should be just

hr = sensor->SetEventSink(pMyEvents);, which will trigger the event asynchronously.

I also used CoInitializeEx(NULL, COINIT_MULTITHREADED); to allow multithreading in COM.

In the comments in the above SO link, two users mention that "You're forgetting the Windows message event loop." I do not want to have a graphical interface for this program, and more importantly I do not get why "COM will not work without a message loop." This seems to apply only for Windows Application Projects. Could someone elaborate on this, and how to properly use SetEventSink(ISensorEvent) to keep receiving the data for a regular console application?

I have confirmed that other code such as for initialization/decoding dataworks by using the synchronous method - GetData().

Taylor
  • 286
  • 4
  • 18
  • Sensor stuff works in the same thread, so COM needs messages to route the calls. – Michael Chourdakis Dec 12 '18 at 19:56
  • [Processes, Threads, and Apartments](https://learn.microsoft.com/en-us/windows/desktop/com/processes--threads--and-apartments). – IInspectable Dec 12 '18 at 22:06
  • Yes, it says that for single threaded apartment, "all COM objects are synchronized with the windows message queue." But it says that if we `CoInitializeEx(NULL, COINIT_MULTITHREADED)`, which makes it a multithreaded apartment, now it is not bound to the windows message queue - free-threaded - so we can simply make everything work with a console application without the Win32Application limitations. So what are some reasons or fixes to why COM Event firing won't work as expected? Please let me know if I am misundertsanding any of the COM related concepts. – Taylor Dec 12 '18 at 22:24
  • Also it says that "Threads in multi-threaded apartments should not perform UI actions." because "this is because UI threads require a message pump, and COM does not pump messages for threads in a multi-threaded apartment." Does a console application count as a GUI, which leads to must I make ithe eventhandler multithreaded to receive any results? – Taylor Dec 12 '18 at 22:41
  • 1
    You need to get a grip on some fundamentals: `1` The author of a COM object decides, which apartment the object can be instantiated in. You cannot arbitrarily choose. `2` *Any* thread can have a message queue. A thread that owns windows always does, but a GUI is not a requirement. A console application's threads can (or must, in the case of an STA) pump messages. `3` Learn what a [mcve] is, and provide one. – IInspectable Dec 13 '18 at 00:32

0 Answers0