SendMessage() WINAPI gets hang when used to connect to a DDE server

I have a DDE client app which connects to the DDE server app by using SendMessage() WINAPI. Following the SendMessage() call which gets hang while requesting connection to the DDE Server. Both DDE Client app and server app are in VC++.

SendMessage((HWND) -1,WM_DDE_INITIATE,(WPARAM) m_hWnd,MAKELPARAM(hService,hTopic));

Now what SendMessage() is doing that it is getting hanged? Basically it is broadcasting WM_DDE_INITIATE window message to all the windows in the system. The window (DDE server) for which it is intended should process the message and should reply with an acknowledgment. Once acknowledgment is received SendMessage() call is completed and client is connected.

In our case it is getting hang and is never returning back, as a result we hav开发者_高级运维e DDE Client application getting hang.

I searched on the net and found that using SendMessage() to broadcast is usually not recommended as it gets hang many times.

I have code for the DDE client app and DDE server app with me.

Let me know is there some way to retrieve the DDE server window handle or some way to assign a unique name to the DDE server window .

By doing this, i believe at the client end i can retrieve the window handle of DDE server from unique name (using FindWindow() winapi) and instead of broadcasting using SendMessage() I can send the message directly to DDE server using window handle.

If you feel above method of getting window handle of DDE server is not possible or not recommended, then do let me know some other method to use SendMessage() winapi to connect to DDE Server.

If another process, any process, is sleeping in their UI thread and not processing messages, broadcast messages will hang. Yet another reason to stop using DDE; it's a leftover from the days of 16-bit Windows when broadcast messages were perfectly safe.

Unfortunately, this is somewhat of a fundamental problem in DDE. The recommended workaround is to simply not use DDE; make use of more modern methods such as named pipes, DCOM, or even TCP sockets.

Use SendMessageTimeout instead of SendMessage so the hung apps will not hang you.