SendMessage() WINAPI зависает при использовании для подключения к серверу DDE
У меня есть клиентское приложение DDE, которое подключается к приложению сервера DDE с помощью SendMessage() WINAPI. После SendMessage() вызов, который зависает при запросе соединения с сервером DDE. Как клиентское приложение DDE, так и серверное приложение находятся на VC++.
SendMessage((HWND) -1,WM_DDE_INITIATE,(WPARAM) m_hWnd,MAKELPARAM(hService,hTopic));
Что теперь SendMessage() делает, что это становится повешенным? В основном это вещание WM_DDE_INITIATE оконное сообщение для всех окон в системе. Окно (сервер DDE), для которого оно предназначено, должно обработать сообщение и ответить подтверждением. Как только подтверждение получено SendMessage() вызов завершен, и клиент подключен.
В нашем случае он зависает и никогда не возвращается обратно, в результате у нас клиентское приложение DDE зависает.
Я искал в сети и обнаружил, что с помощью SendMessage() вещать обычно не рекомендуется, так как он зависает много раз.
У меня есть код для клиентского приложения DDE и серверного приложения DDE.
Дайте мне знать, есть ли какой-нибудь способ получить дескриптор окна сервера DDE или какой-нибудь способ присвоить уникальное имя окну сервера DDE.
Делая это, я считаю, что на стороне клиента я могу получить дескриптор окна сервера DDE с уникального имени (используя FindWindow() winapi) и вместо трансляции использую SendMessage() Я могу отправить сообщение напрямую на сервер DDE, используя дескриптор окна.
Если вы чувствуете, что описанный выше способ получения дескриптора окна сервера DDE невозможен или не рекомендуется, то дайте мне знать, какой другой способ использовать SendMessage() WinAPI для подключения к серверу DDE.
2 ответа
Используйте SendMessageTimeout вместо SendMessage, чтобы зависшие приложения не повесили вас.
Если другой процесс, любой процесс, спит в своем потоке пользовательского интерфейса и не обрабатывает сообщения, широковещательные сообщения будут зависать. Еще одна причина прекратить использование DDE; это пережиток тех времен 16-битной Windows, когда широковещательные сообщения были в полной безопасности.
К сожалению, это несколько фундаментальная проблема в DDE. Рекомендуемый обходной путь - просто не использовать DDE; использовать более современные методы, такие как именованные каналы, DCOM или даже сокеты TCP.