Когда приложение вызывает функцию
DdeCreateStringHandle и указывает строку, которая уже существует, система помещает эту строку в таблицу и генерирует некоторый идентификатор, необходимый для быстрого и корректного доступа к этой строке. Система также сохраняет количество использования каждой строки в этой же таблице.
Если приложение пытается определить строку, которая уже существует в таблице, система просто увеличивает ее количество использования, а при вызове функции DdeFreeStringHandle, соответственно уменьшает на 1. Строка удаляется из таблицы, когда ее количество использования равно 0. Service имена. Регистрация, фильтр.
DDEML позволяет регистрировать service имена для сервера и не посылать транзакцию вида XTYP-CONNECT для неподдрерживаемых service имен в функцию обратного вызова. Остановимся на обсуждении этого вопроса более подробно.
При регистрации service имен в DDEML, сервер информирует другие DDE-приложения в системе о том, что текущий сервер доступен для обмена данными.
Сервер регистрирует service имя путем вызова функции DdeNameService и указывает идентификатор строки, связанной с именем.
При получении вышеуказанных данных DDEML посылает транзакцию вида XTYP-REGISTER в функцию обратного вызова каждого DDEML-приложения в системе (за исключением только тех, которые указали флаг фильтрации GBF_SKIP_REGISTRATION в функции DdeInitialize).
Транзакция XTYP_REGISTER передает два
идентификатора строк в функцию обратного вызова: первый из
них указывает на основное service имя, а второй - на
строку, содержащую системную информацию.
Обычно клиент использует основное service имя в списке всех доступных серверов так, что конечный пользователь может выбрать необходимый ему сервер, перемещаясь по этому списку. Также клиент использует системную информацию для непосредственного установления диалога с сервером.
Сервер может использовать функцию DdeNameServise для того, чтобы сбросить регистрацию service имени. Это оэначает, что DDEML необходимо послать транзакцию вида XTYP_UNREGISTER в оставшиеся DDE-приложения с информацией о том, что они больше не смогут использовать данное service имя для установления диалога.
Сервер должен вызывать функцию DdeNameServise для регистрации его service имени сразу после вызова функции DdeInitialize. Сервер должен сбрасывать свое service имя сразу после вызова функции DdeUninitialize. Помимо регистрации service имени функция DdeNameService поэволяет включать или выключать серверу ее собственный фильтр service имени.
Когда сервер выключает фильтр, DDEML посылает транзакцию вида XTYP_CONNECT в функцию обратного вызова сервера вне зависимости от того совпадают ли вызываемое service имя с зарегистрированным или нет при вызыве клиентом функции DdeConnect. Когда сервер включает фильтр, транзакция вида XTYP_CONNECT посылается лишь в том случае, когда вызываемое service имя совпадает с зарегистрированным.
По умолчанию, фильтр включен лишь тогда, когда приложение вызывает функцию DdeInitialize. Это необходимо для предотвращения генерации транзакции XTYP_CONNECT до того как созданы необходимые идентификаторы строк. Сервер может выключить фильтр путем установки флага DNS_FILTEROFF при вызове функции DdeNameService. Флаг DNS_FILTERON включает фильтр.
Диалог между приложениями
Диалог между клиентом и сервером всегда
устанавливается по требованию клиента. Когда диалог
установлен, оба партнера получают идентификатор, который
описывает данный диалог.
Партнеры используют этот идентификатор в
большинстве функций DDEML для посылки транзакций и для их
обработки. Клиенту может потребоваться диалог как с одним
сервером, так и с несколькими.
Рассмотрим подробно как приложение устанавливает диалог и получает информацию о уже существующих каналах связи.
Простой Диалог
Клиентское приложение устанавливает простой диалог с сервером путем вызова функции DdeConnect и определяет идентификаторы строк, которые содержат всю необходимую информацию о service имени текущего сервера и интересущем клиента в данный момент topic имени.
DDEML отвечает на вызов этой функции посылкой соответствующей транзакции XTYP_CONNECT в функцию обратного вызова каждого доступного в данный момент времени сервера, зарегистрированное имя которого совпадает с именем, переданным при помощи функции DdeConnect при условии, что сервер не отключал фильтр service имени вызовом функции DdeServiceName.
Сервер может также установить фильтр на
XTYP_CONNECT транзакцию заданием соответствующего флага CBF_FAIL_CONNECTIONS при вызове функции DdeInitialize.
В процессе обработки транзакции типа XTYP_CONNECT DDEML передает полученные от клиента service и topic имена серверу. Сервер должен проверить эти имена и возвратить
TRUE, если он в состоянии работать с такими именами, и FALSE в противном случае. Если ни один из существующих серверов не отвечает на CONNECT-запрос клиента, функция DDeConnect возвращает ему NULL с информацией о том, что в данный момент времени НЕ возможно установить диалог.
Однако, если сервер возвратил TRUE, то диалог был успешно установлен и клиент получает идентификатор диалога
- двойное слово, посредством которого и ведется обмен данными с сервером.
Затем сервер получает транзакцию вида
XTYP_CONNECT_CONFIRM (в случае, если он НЕ описывал флаг фильтра CBF_FAIL_CONFIRMS при вызове соответствующей функции).
В нижеприведенном примере производится попытка
установить диалог с сервером, который в состоянии работать с service именем 'My Server' в системном режиме. Считаем, что параметры hszSysTopic и hszServName уже предварительно созданы нами ранее.
HCONV hConv;
HWND hwndParent;
HSZ hszServName;
HSZ hszSysTopic;
. . .
hConv = DdeConnect(
idInst, // Копияприложения
hszServName, // Идентификатор service-имени
handle hszSysTopic, // Идентификатор system-topic-имени (PCONVCONTEXT) NULL); // Используемконтекстпоумолчанию
if( hConv == NULL )
MessageBox( hwndParent, "MyServer НЕдоступен!",
(LPSTR) NULL, MB_OK );
return FALSE;
. . .
В этом примере функция DdeConnect заставляет DDEML посылать транзакцию вида XTYP_CONNECT в функцию обратного вызова сервера MyServer.
А теперь приведем пример функции обратного вызова сервера, который обрабатывает транзакцию XTYP_CONNECT и сравнивает свое зарегистрированное имя с именем, полученным от клиента. Как уже было отмечено ранее, если они совпадают, то сервер в состоянии установить диалог с клиентом.
#define CTOPICS 5
HSZ hsz1; // Идентификатор строки,
полученный от DDEML.
HSZ ahszTopics[CTOPICS]; // Массив поддреживаемых topic имен int i; // Счетчик цикла
.
. // Для обработки транзакций используем стандартную ANSI C . // конструкцию switch --> case --> default.
.
case XTYP_CONNECT:
for (i = 0; i < CTOPICS; i++)
if (hsz1 == ahszTopics[i])
return TRUE; // Установкадиалога
return FALSE; // Topic имя НЕ поддерживается, диалог запрещен.
.
. // Обработка других типов транзакций.
.
Если сервер возвращает TRUE в ответ на транзакцию XTYP_CONNECT, DDEML посылает транзакцию вида XTYP_CONNECT_CONFIRM в функцию обратного вызова данного сервера. Обработав эту транзакцию, сервер может получить идендификатор диалога.
Вместо конкретного имени сервера клиент может установить шаблон диалога путем установки идентификаторов service и topic имен в NULL при вызове функции DdeConnect.
Если хотя бы один из вышеперечисленных
идентификаторов равен NULL, DDEML посылает транзакцию типа
XTYP_WILDCONNECT в функцию обратного вызова всех активных в данный момент DDE-приложений (исключения составляют лишь те, кто при вызове соответствующей функции указал флаг фильтрации XTYP_WILDCONNECT).
Любое сервер-приложение должно ответить на данную транзакцию и возвратить указатель на массив структур типа HSZPAIR, оканчивающийся нулем.
Если сервер-приложение НЕ вызывает функцию
DDeNameService для регистрации собственного service имени в системе и фильтр обработки транзакций включен, то сервер НЕ получит транзакцию вида XTYP_WILDCONNECT.
Вышеописанный массив должен содержать одну
структуру для каждого service и topic имен. DDEML выбирает одну пару из массива для установления диалога и возвращает его идентификатор клиенту. Затем DDEML посылает серверу транзакцию вида XTYP_CONNECT_CONFIRM (исключения составляют лишь те серверы, которые при инициализации установили фильтр обработки транзакций).
Продемонстируем использование транзакции вида
XTYP_CONNECT.
#define CTOPICS 2
UINT uType;
HSZPAIR ahszp[(CTOPICS + 1)];
HSZ ahszTopicList[CTOPICS];
HSZ hszServ, hszTopic;
WORD i, j;
if (uType == XTYP_WILDCONNECT)
// Сканируем список topic имен и создаем массив
// структуртипа HSZPAIR
j = 0;
for (i = 0; i < CTOPICS; i++)
if (hszTopic == (HSZ) NULL ||
hszTopic == ahszTopicList[i])
ahszp[j].hszSvc = hszServ;
ahszp[j++].hszTopic = ahszTopicList[i];
//
// Последний элемент массива всегда NULL.
//
ahszp[j].hszSvc = NULL;
ahszp[j++].hszTopic = NULL;
//
// Возвращаем дискриптор глобального объекта памяти,
// содержащийструктурытипа HSZPAIR.
//
return DdeCreateDataHandle(
idInst, // Копия приложения
(LPBYTE) &ahszp, // Указатель на массив типа HSZPAIR
sizeof(HSZ) * j, // Длина массива
0, // Начальное смещение
(HSZ) NULL, // item-имя не существует
0, // формат item-имени также
// не существует
0); // Возлагаем все работу
// с массивом на систему
Любой сервер или клиент может оборвать диалог в любое время путем вызова функции DdeDisconnect. Это означает, что партнер по обмену данными получает транзакцию типа XTYP_DISCONNECT в функции обратного вызова (если, конечно, партнер не установил фильтр обработки транзакций вида CBF_SKIP_DISCONNECTIONS).
Обычно приложение реагирует на транзакцию
XTYP_DISCONNECT вызовом функции DdeQueryInfo для получения информации о прекращенном диалоге. После того, как функция обратного вызова обработала транзакцию типа XTYP_DISCONNECT, идентификатор диалога больше не существует.
Клиентское приложение, которое получает транзакцию типа XTYP_DISCONNECT в своей функции обратного вызова может попытаться возобновить диалог при промощи вызова
функции DdeReconnect. Клиентское приложение может вызывать
эту функцию только находясь внутри своей собственной
функции обратного вызова.
Сложный диалог
Клиентское приложение может использовать функцию DdeConnectList для того, чтобы определить какие сервер-приложения существуют в системе в данный момент времени.
Клиент обязательно должен описывать service и topic имена, когда он вызывает эту функцию; это означает, что DDEML должна послать транзакцию вида XTYP_CONNECT все функции обратного вызова всех имеющихся в данный момент сервер-приложений, чьи зарегистрированные имена совпадают с именами, указанными клиентом (исключение составляют лишь те серверы, которые фильтруют получаемые транзакции).