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