максимально увеличивает эффективность работы, а также работу с
сервером в системном режиме. Сервер, в свою очередь, должен под-
держивать нижеописанные item имена, а также другие, часто ис-
пользуемые клиентом:
SZDDESYS ITEM TOPICS - список item имен, с которыми может
работать сервер в данный момент времени. Этот список может изме-
няться время от времени.
SZDDESYS ITEM SYSITEMS - список item имен, с которыми мо-
жет работать сервер в системном режиме.
SZDDDESYS ITEM STATUS - запросить текущий статус сервера.
Обычно, данный запрос поддерживается только в формате CF_TEXT и
содержит строку типа Готов/Занят.
SZDDE ITEM ITEMLIST - список item имен, поддерживаемых сер-
вером в несистемном режиме работы. Этот список может меняться
время от времени.
SZDDESYS ITEM FORMATS - список строк, представляющий собой
список всех форматов почтового ящика, поддерживаемых сервером в
данном диалоге. Например, CF_TEXT формат представлен строкой TEXT.
Основное назначение и работа функции обратного вызова
Приложение, которое использует DDEML, должно содержать фун-
кцию обратного вызова, которая обрабатывает события, полученные
приложением. DDEML уведомляет приложение о таких событиях путем
посылки транзакций в функцию обратного вызова данного приложения.
В зависимости от флага фильтра транзакции, сформированного
при вызове функции DdeInitialize, функция обратного вызова полу-
чает отсортированные транзакции вне зависимости от того, являет-
ся ли данное приложение клиентом, сервером или тем и другим од-
новременно. Следующий пример демонстрирует наиболее типичное ис-
пользование функции обратного вызова.
HDDEDATA CALLBACK DdeCallback( uType, uFmt, hconv, hsz1,
hsz2, hdata, dwData1, dwData2 )
UINT uType; // Тип транзакции
UINT uFmt; // Формат почтого ящика
HCONV hconv; // Идентификатор диалога
HSZ hsz1; // Идентификатор строки #1
HSZ hsz2; // Идентификатор строки #2
HDDEDATA hdata; // Идентификатор глобального объек-
та памяти
DWORD dwData1; // Данные текущей транзакции #1
DWORD dwData2; // Данные текущей транзакции #2
{
switch (uType)
{
case XTYP_REGISTER:
case XTYP_UNREGISTER:
. . .
return (HDDEDATA) NULL;
case XTYP_ADVDATA:
. . .
return (HDDEDATA) DDE_FACK;
case XTYP_XACT_COMPLETE:
. . .
return (HDDEDATA) NULL;
case XTYP_DISCONNECT:
. . .
return (HDDEDATA) NULL;
default:
return (HDDEDATA) NULL;
}
}
Параметр uType идентифицирует тип посланной транзакции в
функцию обратного вызова при помощи DDEML. Значения оставшихся
параметров зависят от типов транзакции. Типы транзакций будут об-
суждены нами в разделе "Обработка Транзакций".
Диалог между приложениями
Диалог между клиентом и сервером всегда устанавливается по
требованию клиента. Когда диалог установлен, оба партнера полу-
чают идентификатор, который описывает данный диалог.
Партнеры используют этот идентификатор в большинстве фун-
кций 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 все функции обратного вызо-
ва всех имеющихся в данный момент сервер-приложений, чьи зарегис-
трированные имена совпадают с именами, указанными клиентом (ис-