ключение составляют лишь те серверы, которые фильтруют получае-
мые транзакции).
В добавление к вышесказанному, можно отметить, что клиент,
при вызове функции 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;
ile((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)] = '\0';
// Создаем глобальный объект и
// возвращаем его идентификатор
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-объект, иденти-
фицирующий этот идентификатор НЕ может быть изменен, однако он
может быть уничтожен.
OLE-технология
Как видно из описанного выше протокола DDE, приложения
должны обязательно знать типы передаваемых данных, уметь их обра-
батывать, а в основном даже могут работать только с символьными
строками. Это, конечно, не очень удобно, когда необходимо, напри-
мер, создать небольшой текст с различными картинками, пиктограм-
мами и другими наглядными или не очень иллюстрациями. В этом слу-
чае на помощь программисту проиходит OLE - встраивание объектов.
Вместе с данными мы получаем машинный код, который эти данные мо-
жет обрабатывать.
Способы упорядочивания, источники и целевые документы
При использовании OLE-технологии пользователь всегда имеет
дело с одним ведущим приложением (главным) и одним ведомым (под-
чиненным), а точнее, содним ведомым.
Приложение, с помощью которого получен объект для встраива-
ния всегда играет роль подчиненного. Это особенно характерно для
случаев передачи объектов при встраивании и связывании через бу-
фер промежуточного обмена.
Часто используемые термины Приложение-источник и Целевое
приложение касаются не подчинения приложений, а определяют генеа-
логию объектов.
Некоторые Windows-приложения могут выступать только в роли
подчиненных, а некоторые только в роли ведущих. Например,
Paintbrush в OLE технологии может играть только роль подчиненно-
го приложения, служащего для создания и модификации отдельных
объектов. Другие приложения, например, Write или Cardfile можно
считать оправданным с точки зрения, что гораздо чаще приходится
вставлять иллюстрации в сложные по структуре текст, чем текст в
иллюстрации. Новые приложения,такие как Word, могут выполнять в
рамках OLE обе эти функции.
Употребление термина объект считается престижным в кругах
программистов, хотя часто он употрябляется и не к месту. Всякий
разработчик почитает своим долгом применить в своем продукте ООП
без особой на то необходимости. В среде Windows в термин объект
вкладывается несколько специфический смысл. Пользователя не приг-
лашают постигать азы ООП, или заняться конструированием объектов