dragging an app's debug window locks the app (COM)

dragging an app's debug window locks the app (COM)

Post by Vlad Mitli » Thu, 02 Sep 1999 04:00:00

I made a debug window in the app I am working on, a part of a COM component.  Then I noticed that any message-generating activities on this window (using the scroll bar or just dragging the window)locks my app. This is a multithreaded app that heavily uses synchronization tools (mutexes, events, messages).

I found numerous references (in Microsoft documentation) of potential problems in using WaitForMultipleObjects function with COM, instead of MsgWaitForMultipleObjects.  They say that since all input messages (say from dragging the debug window) are broadcasted over all windows of a thread (if CoInitialize is called - an apartment is created in the client thread) using WaitForMultipleObjects may create deadlocks (all these parasite messages are not removed from the queue of the COM-generated hidden window).  So I rewrote this app hoping that using MsgWaitForMultipleObjects would fix the problem.  Not at all!  same deadlock.  

Another possibility is that the CSingleLock class I use for locking common resources, uses WaitForSingleObject (in .Lock()) - maybe it is stuck there?  But this would mean that when using COM you have to use a home-made lock class processing these parasite messages, instead of using MFC locks.

Anyway, I am still did not get anywhere. Any ideas?

-----------------** -- Posted from CodeGuru -- **-----------------
http://www.codeguru.com/    The website for Visual C++ programmers.


1. Java app calling Java app through command.com loses env vars

I'm starting to use a product that has one step of its installation/setup that
is a cmd script that calls a Java application that ends up using command.com to
call another Java application.  The last Java application needs to references
environment variables set in the cmd script.

In Windows 2000, this process works fine.  The last Java application sees the
environment variables fine.  In Windows XP, however, the last Java application
seems to have no environment variables (I've only tried several, but I haven't
checked to see if there are any at all).

I wish they had written this process better (as the second Java application has
a relatively easy-to-use API that they could have just called directly from the
first Java application), but they didn't.  I don't expect them to re-architect
this any time soon.

The question I have is, is there something that changed between Win2k and WinXP
in the area of calling other applications through command.com, such that a
downstream called application wouldn't be able to get any environment

Is there something they're supposed to use instead of "command.com" for this
sort of thing?  I know there's "cmd" and "command", and "cmd" appears to be
much more functional, but I don't know a lot about the differences between

David M. Karr          ; Java/J2EE/XML/Unix/C++

2. Audio in NetMeeting

3. DOS apps can't use COM in Windows?

4. numlock

5. OLE2 drag 'n drop in non-container apps

6. DVD player Problem

7. Can't debug my app


9. 16 Bit app slows with windows apps on XP

10. WH_Shell, NTVDM, 16bit App, non-based window App...

11. Interface between 16Bit DOS or 32Bit Console App and Win GUI app under Windows NT

12. Strouds Consummate Winsock Apps for September 15 - Get the latest and greatest Windows/Winsock Apps now!

13. Communicating with Dos app from Windows app?