Ungi - 2012-05-23

I've been using WTL to develop an EXE COM server for some time and have run accross issues where I'm not sure are bugs or just a product of my misunderstanding of the technology.

1. Why isn't CoInitialize(Ex) called for each Thread in the template "root.cpp"? An ideal place for this would be the "RunThread" method. Is there a special reason for not doing so?

2. When using COM automation, why is in _tWinMain the message loop not registered previously with with _Module? (This basically prevents idle handling by the COM object) Again is there a reason for not doing so? (Applications with automation may also need idle processing after all)
Could the respective lines _Module.AddMessageLoop(&theLoop); and _Module.RemoveMessageLoop(); be added before/after theLoop.Run() call?

3. Why does the main thread in the ThreadManager's run method not contain message passing code? As the default COM init of the main thread done in _tWinMain calls CoInitialize(), it automatically enters a COM STA, which in turn requires "Each single-threaded apartment must have a message loop to handle calls from other processes and apartments within the same process" (see http://msdn.microsoft.com/en-us/library/windows/desktop/ms680112(v=vs.85).aspx). Is their a special reason for not having the normal PeekMessage/DispatchMessage combo? (TranslateMessage not being necessary for the main thread as acceleration is not used)

Of these particularly the last issue bit me. I was receiving WM_USER messages from the OleAutomation hidden window from time to time, which got misinterpreted as the 'create new window' in my WTL Multithread SDI app.
Would a patch explicitly checking the main thread MSG structure for wParam = lParam = hwnd = 0 (i.e.: the PostThreadMessage call from the main frame) have any adverse effects?