Windows
Topic имя - это строка, которая идентифицирует логический контекст данных. Для сервера, который манипулирует файлами, topic имена это просто названия
файлов; для других серверов - это специфические имена
конкретного приложения. Клиент обязательно должен
указывать topic имя вместе с service именем, когда он
хочет установить диалог с сервером.
Item имя - это строка, которая идентифицирует некоторое множество данных, которое сервер может передать клиенту в процессе транзакции. Например, item имя может идентифицировать ЦЕЛОЕ ( int, integer ), СТРОКУ ( string, char * ), несколько параграфов текста, или BITMAP образ.
Все вышеуказанные имена позволяют клиенту
установить диалог с сервером и получить от него данные.
Системный режим
Системный режим работы обеспечивает клиента всей необходимой информцией о сервере.
Для того, чтобы определить, какие серверы доступны в данный момент времени, а также какой информацией они могут обеспечить клиента, последний, находясь в начальном режиме работы, должен установить имя устройства, равное NULL. Такой шаблон диалога максимально увеличивает эффективность работы, а также работу с сервером в системном режиме. Сервер, в свою очередь, должен поддерживать нижеописанные 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, приложение должно вызвать функцию DdeInitialize. Эта функция получает идентификатор копии данного приложения, регистрирует функцию обратного вызова приложения посредством DDEML и указывает флаг фильтра транзакции для функции обратного вызова.
Каждое приложение или DLL должно содержать
идентификатор своей копии, например, в параметре idInst.
Он необходим любой функции DDEML. Это очень легко поддается объяснению: назначение DDEML - поддержка механизма DDE в приложениях, несколько копий которых может быть запущено в данный момент времени. Однако приложение НЕ МОЖЕТ использовать более одной копии DDEML.
Фильтр транзакции оптимизирует эффективность
системы путем предотвращения передачи нежелательных типов транзакций в функцию обратного вызова. Приложение устанавливает фильтр транзакции при вызове функции DdeInitialze. Приложение должно указать флаг фильтра транзакции для каждого типа транзакции, которые не будут обрабатываться в функции обратного вызова. Однако любое приложение может изменить фильтр транзакции путем дополнительного вызова функции DdeInitialize. Приведем пример инициализации DDE-диалога.
DWORD idInst = 0;
HINSTAINCE hInst;
DdeInitialize( &idIns, // Копия приложения
( PFNCALLBACK ) DdeCallback, // Адрес CallBack функции CBF_FAIL_EXECUTES | // Фильтр XTYPE_EXECUTE CBF_SKIP_ALLNOTIFICATIONS, 0 );// Фильтр NOTIFICATIONS
Каждое приложение должно вызывать функцию
DdeUninitialize, когда оно больше не собирается
использовать DDEML. Эта функция прекращает текущий диалог и освобождает ресурсы DDEML, предоставленные системой для установления диалога.
Основное назначение и работа функции обратного вызова
Приложение, которое использует 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 функций требуют наличия доступа к строкам. Например, клиент должен в явном виде указывать service и topic имена, когда приложение вызывает функцию DdeConnect для установления диалога с сервером. Приложение указывает строку путем передачи ее идентификатора в соответствующее место (также как и в случае указателя на DDEML функцию). Идентификатор строки - это двойное слово, определяемое системой.
Приложение может получить идентификатор строки
путем вызова соответствующей функции
DdeCreateStringHandle. Эта функция регистрирует строку в системе и возвращает ее идентификатор приложению. Следующий пример получает идентификатор строки для строк System topic и Service-name.
HSZ hszServName;
HSZ hszSysTopic;
. . .
hszServName = DdeCreateStringHandle(
idInst, // Копия приложения
"MyServer", // Строка для регистрации
CP_WINANSI); // Кодовая страница Windows ANSI
hszSysTopic = DdeCreateStringHandle(
idInst, // Копия приложения
SZDDESYS_TOPIC, // Строка для регистрации CP_WINANSI); // Кодовая страница Windows ANSI
. . .
Параметр idInst содержит идентификатор,
возвращенный функцией DdeInitialize.
Функция обратного вызова получает один или более строковых идентификаторов при обработке большинства DDE-транзакций. Например, сервер получает два идентификатора строк в процессе транзакции типа XTYP_REQUEST: один идентификатор - это строка, описывающая topic имя, а другой - item.
Приложение может получать длину строки,
соответствующую идентификатору строки и копировать эту
строку в некоторый буфер, предварительно зарезервированный
приложением.
Все вышеуказанные действия можно проделать при помощи вызова функции DdeQueryString, как продемонстрировано в следующем примере:
DWORD idInst;
DWORD cb;
HSZ hszServ;
PSTR pszServName;
. . .
cb = DdeQueryString(idInst, hszServ, (LPSTR) NULL, 0,
CP_WINANSI) + 1;
pszServName = (PSTR) LocalAlloc(LPTR, (WORD) cb);
DdeQueryString(idInst, hszServ, pszServName, cb, CP_WINANSI);
. . .
Итак, функция DdeQueryString создает строку,
используя строковый идентификатор, а затем функция
DdeCreateStringHandle создает строковый идентификатор из строки. Следует отметить, что два идентификатора НЕ СУЩЕСТВУЮТ в одно и тоже время.
DWORD idInst;
DWORD cb;
HSZ hszInst, hszNew;
PSZ pszInst;
. . .
DdeQueryString(idInst, hszInst, pszInst, cb, CP_WINANSI); hszNew = DdeCreateStringHandle(idInst, pszInst, CP_WINANSI); // hszNew != hszInst !
. . .
При возвращении некоторого значения функцией
обратного вызова идентификатор строки портится. В
приложении можно сохранить идентификатор при помощи функции DdeKeepStringHandle и использовать этот идентификатор после вызова функции CallBack.
Когда приложение вызывает функцию
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 все функции обратного вызова всех имеющихся в данный момент сервер-приложений, чьи зарегистрированные имена совпадают с именами, указанными клиентом (исключение составляют лишь те серверы, которые фильтруют получаемые транзакции).
В добавление к вышесказанному, можно отметить, что клиент, при вызове функции DdeConnectList, может указать NULL в качестве service или topic имени, либо же сразу для обоих. Все доступные в системе серверы, чьи зарегистрированные имена совпадают с именами, указанными клиентом, отвечают на его запрос. Диалог устанавливается со всеми такими серверами, даже если в системе запущено одно и тоже сервер-приложение несколько раз.
Клиент может использовать функции
DdeQueryNextServer и DdeQueryConvInfo для того, чтобы понять, какой сервер находится в списке, полученный при вызове функции DdeConnectList. DdeQueryNextServer возвращает идентификатор диалога для следующего сервера, находящегося в списке; DdeQueryConvInfo заполняет структуру CONVINFO информацией о диалоге.
Клиент может сохранить полученные идентификаторы диалогов и отказаться от просмотра оставшихся серверов в списке.
Приведем пример использования функции
DdeConnectList для установления диалога со всеми
серверами, которые поддерживают имя 'system topic', затем
будем использовать функции DdeQueryConvInfo и
DdeQueryNextServer для получения их идентификаторов
service имен, одновременно не забывая сохранить последние
во временном буфере.
HCONVLIST hconvList; // Список диалогов
DWORD idInst; // Дискриптор приложения
HSZ hszSystem; // System topic
HCONV hconv = NULL; // Идентификатор диалога
CONVINFO ci; // Информация о диалоге
UINT cConv = 0; // Количество идентификаторов диалогов
HSZ *pHsz, *aHsz; // Указатель на идентификатор строки
// Присоединяемся ко всем серверам, поддерживающим
// System topic.
hconvList = DdeConnectList(idInst, NULL, hszSystem,
NULL, NULL);
// Вычисляем количество серверов в списке.
while((hconv = DdeQueryNextServer(hconvList,hconv)) != NULL)
cConv++;
// Выделяем буфер для сохранения идентификаторов строк.
hconv = NULL;
aHsz = (HSZ *) LocalAlloc(LMEM_FIXED, cConv * sizeof(HSZ));
// Копируем идентификатор строки в буфер.
pHsz = aHsz;
while((hconv = DdeQueryNextServer(hconvList,hconv)) != NULL)
DdeQueryConvInfo(hconv, QID_SYNC, (PCONVINFO) &ci);
DdeKeepStringHandle(idInst, ci.hszSvcPartner);
*pHsz++ = ci.hszSvcPartner;
.
. // Используем идентификатор: 'общаемся' с сервером.
.
// Освобождаем память и прекращаем диалог.
LocalFree((HANDLE) aHsz);
DdeDisconnectList(hconvList);
Приложение может оборвать индивидуальный диалог, находящийся в списке диалогов путем вызова функции DdeDisconnect; приложение может оборвать все диалоги, находящиеся в списке путем вызова функции DdeDisconnectList.
Обе вышеуказанные функции указывают DDEML о
необходимости посылки транзакции вида XTYP_DISCONNECT во
все функции партнеров по диалогу данного приложения (в
случае использования функции DdeDisconnectList будет
посылаться транзакция XTYP_DISCONNECT для каждого элемента
в списке диалогов).
Обмен данными между приложениями
Так как DDE использует области памяти для передачи данных из одного приложения в другое, DDEML обеспечивает конечного программиста функциями, при помощи которых DDE-приложения могут создавать и обрабатывать DDE-объекты.
Весь спектр транзакций, который вызывает обмен данными, требует от приложения, экспортирующего их, создания некоторого буфера, содержащего эти данные, а затем вызова функции DdeCreateDataHandle.
Эта функция создает DDE-объект, копирует данные из буфера в этот объект и возвращает идентификатор данных для
данного приложения.
Идентификатор данных-это двойное слово, которое использует DDEML для обеспечения доступа к данным в DDE-объекте.
Для того, чтобы разделять данные в DDE-объекте, приложение передает идентификатор данных DDEML, а затем DDEML передает его в функцию обратного вызова приложения, получающего данные.
В нижеприведенном примере показано, как создать DDE-объект и получить его идентификатор. В процессе обработки транзакции типа XTYP_ADVREQ, функция обратного вызова конвертирует текущее время в ASCII строку, копирует строку в вспомогательный буфер, а затем создает DDE-объект, содержащий вышеуказанную строку. Функция обратного вызова возвращает идентификатор DDE-объекта DDEML, которая передает этот идентификатор клиентскому приложению.
typedef struct tagTIME
INT hour; // 0 - 11 формат времени для часов.
INT hour12; // 12-ой формат.
INT hour24; // 24-ой формат.
INT minute;
INT second;
INT ampm; // 0 --> AM , 1 --> PM
TIME;
HDDEDATA EXPENTRY DdeCallback
(uType, uFmt, hconv, hsz1, hsz2, hdata, dwData1, dwData2)
UINT uType;
UINT uFmt;
HCONV hconv;
HSZ hsz1;
HSZ hsz2;
HDDEDATA hdata;
DWORD dwData1;
DWORD dwData2;
CHAR szBuf[32];
switch (uType)
case XTYP_ADVREQ:
case XTYP_REQUEST:
if ((hsz1 == hszTime && hsz2 == hszNow) &&
(uFmt == CF_TEXT))
// Копируем строку в буфер.
itoa(tmTime.hour, szBuf, 10);
lstrcat(szBuf, ":");
if (tmTime.minute < 10)
lstrcat(szBuf, "0");
itoa(tmTime.minute, &szBuf[lstrlen(szBuf)], 10);
lstrcat(szBuf, ":");
if (tmTime.second < 10)
strcat(szBuf, "0");
itoa(tmTime.second, &szBuf[lstrlen(szBuf)], 10);
szBuf[lstrlen(szBuf)] = ' ';
// Создаем глобальный объект и возвращаем его
// идентификатор
return (DdeCreateDataHandle(
idInst, // копия приложения
(LPBYTE) szBuf, // исходный буфер
lstrlen(szBuf) + 1,
0, // смещение от его начала
hszNow, // item-имя
CF_TEXT, // формат почтого ящика
0));
else return (HDDEDATA) NULL;
.
. // Обработка других типов транзакций.
.
Клиентское приложение получает указатель на
DDE-объект путем передачи идентификатора данных функции DdeAccessData. Указатель, возвращаемый этой функцией, обеспечивает доступ к данным в формате 'ТОЛЬКО НА ЧТЕНИЕ'. Клиент должен просмотреть полученные данные при помощи этого указателя и вызвать функцию DdeUnaccessData для его уничтожения. Клиент может скопировать полученные данные в заранее приготовленный буфер посредством вызова функции DdeGetData.
В следующем примере мы получим указатель на DDE-объект, сохраним его в параметре hData, скопируем содержимое во временный буфер и уничтожим указатель:
HDDEDATA hdata;
LPBYTE lpszAdviseData;
DWORD cbDataLen;
DWORD i;
char szData[32];
. . .
case XTYP_ADVDATA:
lpszAdviseData = DdeAccessData(hdata, &cbDataLen);
for (i = 0; i < cbDataLen; i++)
szData[i] = *lpszAdviseData++; DdeUnaccessData(hdata); return (HDDEDATA) TRUE;
. . .
Обычно, когда приложение, создающее идентификатор данных, передает его DDEML, этот идентификатор портится внутри вышеуказанного приложения. В этом нет ничего страшного, если сервер должен разделять данные только с одним клиентом. Если же сервер должен разделять данные сразу с несколькими клиентами одновременно, ему придется указывать флаг HDATA_APPOWNED при вызове функции
DdeCreateDataHandle.
Это делает возможным получение прав собственности на DDE-объект сервер-приложения и предотвращает порчу идентификатора данных DDEML. Приложение может передавать DDEML идентификатор данных любое количество раз, однако вызывать функцию DdeCreateDataHandle можно лишь однажды.
Если приложение указывает флаг HDATA_APPOWNED в параметре atCmd при вызове функции DdeCreateDataHandle, оно обязательно должно вызывать функцию DdeFreeDataHandle для очистки памяти вне зависимости от того, передавался ли идентификатор данных DDEML или нет. Перед тем как оборвать диалог, приложение должно вызывать функцию DdeFreeDataHandle для очистки всех созданных идентификаторов, но которые так и не были переданы DDEML.
Если приложение еще не передало идентификатор DDE-объекта DDEML, то оно может добавить данные к уже существующему объекту или полностью заменить их в нем. Все эти сервисные функции обслуживаются функцией DdeAddData.
Обычно приложение использует эту функцию для новой инициализации старых не уничтоженных DDE-объектов. После того, как приложение передает идентификатор данных DDEML, DDE-объект, идентифицирующий этот идентификатор НЕ может быть изменен, однако он может быть уничтожен.
Классы транзакций
DDEML содержит четыре класса транзакций. Каждый класс описывается некоторой константой, начинающейся с префикса XCLASS. Эти классы полностью описаны в соответствующем заголовочном файле DDEML. Каждая константа является комбинацией типов транзакций и передается функции обратного вызова приложения, получающего данные от сервера в текущий момент времени.
Вышеописанные классы определяют возвращаемое
значение, которое ожидает получить DDEML от функции
обратного вызова приложения, обрабатывающего данную
транзакцию. Ниже представлена сводная таблица возвращаемых
значений функции обратного вызова, а также типов
транзакций, связанных с каждым из четырех классов
транзакций.
-
Класс Возвращ е значение Транзакция XCLASS_BOOL TRUE или FALSE TYP_ADVSTART
TYP_CONNECT
XCLASS_DATA Идентификатор
данных,
CBR_BLOCK или NULL
XTYP
XTYP
XTYP
ADVREQ
REQUEST
WILDCONNECT
XCLASS_FLAGS Флаг транзакций:
DDE_FACK
DDE_FNOTPROCESSED
DDE_FBUSY
XTYP_ADVDATA
XTYP_EXECUTE
XTYP_POKE
XCLASS_NOTIFICATION Не возвращает XTYP
XTYP
XTYP
XTYP
XTYP
XTYP
XTYP
ADVSTOP
CONNECT_CONFIRM
DISCONNECT
ERROR
REGISTER
UNREGISTER
XACT_COMPLETE
Определение ошибок
Если исполнение DDEML-функции завершилось аварийно, приложение может вызвать функцию DdeGetLastError для определения причины сбоя. DdeGetLastError возвращает код ошибки, по-которому можно определить причины фатального завершения DDEML-функции.
-49-
СПИСОК ЛИТЕРАТУРЫ
1. НОРТОН П., ЙАО П. Программирование на Borland C++ в среде Windows: В 2-х томах. Киев:"Диалектика", 1993.
2. Гладков С.А. Фролов Г.В. Программирование в Microsoft Windows:
В 2-х частях. М.:"ДИАЛОГ-МИФИ", 1992.
3. Microsoft Windows Software Development Kit. Version 3. Programmer's Reference, Programming Tools, Windows Extensions.
4. Charles Petzold. Programming Windows. Microsoft Press.
5. Библия Windows 3.X. М.: И.В.К. - Софт, 1992.