Mega Code Archive

Outofprocexebugs

This from Delphi@elists.com, on how to possibly solve a bug with a COM out-of-process .EXE... I find it very difficult to imagine how the language an out-of-proc COM server is written in affects client-side DDE. After all, (assuming the object is using standard marshalling) the only code which is in the client process is the proxy-stub which COM creates itself based on the type library. There is no way the client process can tell that the object on the other end of the wire is written in Delphi. I would suggest a few more tests & questions: - does the DDE work if you just start up the .exe COM server not via COM, but normally, so that it is just running at the same time as the client but not communicating with it? - does your client app. continue to process window messages correctly whilst the DDE problem is occurring? (I guess DDE is dependent on windows messages, so one problem might be with the app not properly servicing the message queue whilst it's doing COM stuff) - does your reference in-proc object (the C++ one) have exactly the same settings in the registry as the Delphi one (meaning threading model, etc)? Maybe you could post both the registry excerpts. - do you see other DDE problems at the same time as your DDE is affected? For example, launching a program via. a file association (where the 'use DDE' checkbox is ticked). - what platforms are the client & server on? The most likely cause of the problem seems to be the following documented problem with DCOM95 v1.1 (there were no other refs to the Q, so I don't know whether they've fixed it yet): >------------------------------------ FROM KB Q181949 SYMPTOMS Due to a bug in the RPC runtime DLLs that ship with DCOM951.1, MTA clients that do not service the message queue may block the global broadcast of DDE messages. When a user double-clicks on a desktop icon, the program associated with the icon may be blocked from launching and Windows Explorer may hang. >.... RESOLUTION To work around this bug, you need to make the client's MTA thread behave like an STA thread (that is, it must service the message queue). If it is blocking on a win32 handle, it must call the MsgWaitForMultipleObjects() API to simultaneously dispatch windows messages. See the REFERENCES section for an article that explains how to do this. >------------------------------------ I also found a reference to a related issue in the DCOM98 Release Notes: >------------------------------------ FROM KB Q196208 C. Known Issues Affecting Developers MTA Clients That Use BSTR Conversion Routines May Block DDE Messages OLE Automation BSTR conversion routines (such as BstrFromR4) create hidden windows to facilitate the type conversion. These windows do not service the Windows message queue. If such a window is created from within a Multi- Threaded Apartment client, DDE messages may be blocked. The client thread has no obligation to service the message queue under the MTA programming model. If it does not, this top-level window causes global broadcast messages to block. There are two ways to work around this situation: either call the BSTR conversion routines from within an STA client, or make the client's MTA thread behave like a Single-Threaded Apartment thread. (That is, it must service the message queue.) If it is blocking on a win32 handle, it must call the MsgWaitForMultipleObjects() API to simultaneously dispatch windows messages. >----------------------------------- HTH, Andrew Barber AIM