1. Подготовка данных для передачи в Clipboard;

Посылку данных рассмотрим на примере передачи в Clipboard ASCIIZ - строки.

1) Выделяем блок динамической памяти:

GHandle := GlobalAlloc(GMEM_MOVEABLE, StrLen(P) + 1);

Где:

GHandle : THandle - ссылка на блок динамической памяти;

P : PChar - указатель на передаваемую строку.

2) Фиксируем блок от перемещений на время передачи в него данных и одновременно получаем указатель на блок:

GPtr := GlobalLock(GHandle);

Где: GPtr : PChar - указатель на блок.

3) Копируем строку в память:

StrCopy(GPtr, P).

4) Разрешаем перемещение блока памяти:

GlobalUnlock(GHandle).

2. Открытие Clipboard

Открытие Clipboard выполняется вызовом функции

OpenClipboard(),

которая возвращает True, если Clipboard не используется другим приложением. В этом случае возможны последующие действия с Clipboard.

3. Очистка Clipboard

Очистка Clipboard выполняется вызовом функции

EmptyClipboard(),

перед засылкой туда новых данных.

4. Посылка данных в Clipboard

Посылка данных в Clipboard заключается в передаче Clipboard ссылки на блок данных с указанием формата этих данных. Эти действия осуществляются с помощью функции:

SetClipboardData(cf_Text, GHandle).

После вызова этой функции Clipboard начинает владеть данными.

5. Закрытие Clipboard

Закрытие Clipboard выполняется вызовом функции

CloseClipboard(),

после которого Clipboard становится доступным другим приложениям.

Прием данных из Clipboard

Прием данных из Clipboard включает в себя следующие этапы:

1. Открытие Clipboard;

2. Проверка наличия требуемого формата данных в Clipboard;

3. Чтение данных из Clipboard;

4. Закрытие Clipboard.

1. Открытие Clipboard

Открытие Clipboard выполняется аналогично предыдущему случаю вызовом функции:

OpenClipboard().

2. Проверка наличия требуемого формата данных в Clipboard

Проверка наличия требуемого формата данных выполняется вызовом функции:

IsClipboardFormatAvailable(cf_Text),

которая возвращает True, если данные запрашиваемого формата присутствуют.

3. Чтение данных из Clipboard

Чтение данных, в случае успешного выполнения всех предыдущих операций, выполняется за несколько шагов:

1) Получение ссылки на блок памяти, содержащий данные требуемого формата:

GHandle := GetClipboardData(cf_Text);

2) Получение адреса данного блока памяти и фиксирование его от возможных перемещений на время считывания данных:

GPtr := GlobalLock(GHandle);

3) Выделение локальной памяти для чтения в нее интересующих данных:

GetMem(P, StrLen(GPtr) + 1);

4) Копирование данных из глобальной памяти в локальную память:

StrCopy(P, GPtr);

5) Разрешение перемещения глобального блока памяти:

GlobalUnlock(GHandle).

4. Закрытие Clipboard

Закрытие Clipboard в случае приема данных выполняется аналогично закрытию в случае передачи данных: CloseClipboard.

Как видно из приведенного описания, для программной реализации обмена данными через Clipboard требуется выполнения достаточно большого количества действий. При этом, реализация обмена для других, более сложных форматов, таких, например, как "графическое изображение", становится еще более сложной.

Поддержка обмена данными через Clipboard в современных средах программирования

Современные среды проектирования позволяют существенно облегчить работу программиста по реализации обмена данными.

Посмотрим, как можно реализовать обмен данными через Clipboard в среде проектирования Delphi.

Среда проектирования Delphi предоставляет объект TClipboard, который включает в себя все необходимые действия для управления Clipboard.

Включение модуля Clipbrd в состав проекта, автоматически создает, открывает и делает доступным экземпляр Clipboard. При этом, компоненты TEdit и TMemo, обеспечивающие работу с текстовыми строками, а также компонент TImage, обеспечивающий работу с графическими образами, получают возможность использования своих методов работы с Clipboard.

Так, например, скопировать информацию в Clipboard, из компонента Memo типа TMemo, можно следующим образом:

Memo.SelectAll; выделить весь текст

Memo.CopyToClipboard; скопировать выделенный текст

возможен другой метод:

Clipboard.AsText := Memo.Text;

Вырезать текст можно следующим образом:

Memo.SelectAll; выделить весь текст

Memo.CutToClipboard; вырезать выделенный текст

Скопировать текст из Clipboard можно следующим образом:

Memo.PasteFromClipboard; или:

Memo.Text := Clipboard.AsText;

Перед считыванием данных из Clipboard целесообразно проверить, есть ли в Clipboard данные требуемого типа. Это можно сделать с помощью вызова метода объекта Clipboard:

Clipboard.HasFormat(cf_Text),

который вернет True, если данные в формате cf_Text есть в Clipboard.

Для обмена графической информацией следует использовать специально предназначенный для этого метод Assign, примеры использования которого приведены ниже.

Копирование графических данных (в формате cf_BitMap) свойства Picture компонента Image типа TImage в Clipboard:

Сlipboard.Assign(Image.Picture).

Копирование графических данных из Clipboard в компонент Image:

If Clipboard.HasFormat(cf_BitMap) Then begin

Image.Picture.Assign(Clipboard);

End;

Как видно из приведенных примеров, современная среда проектирования программ берет на себя большое количество проблем, имеющих место при организации обмена данными различных форматов через Clipboard.

6.3.4. Обмен данными по технологии DDE

Обмен данными через Clipboard выполняется, как правило, при непосредственном участии пользователя.

В том случае, когда требуется непосредственный обмен данными между приложениями, может быть использован протокол обмена DDE.

DDE - это вид (или протокол) взаимодействия между приложениями, который использует разделяемую память для обмена данными между ними.

Технология DDE не получает широкого распространения из-за сложности реализации, но занимает промежуточное место между технологией Clipboard и технологией OLE, которая тоже чрезвычайно сложна, но развивается.

Технология DDE полностью вписывается в технологию Клиент-Сервер, элементы которой были рассмотрены ранее. Т.е. обмен данными по протоколу DDE происходит между двумя приложениями, одно из которых является клиентом, а другое сервером. Сервер загружается и ждет запросов на обслуживание от клиента. Клиент посылает серверу запрос на получение данных или выполнение работы. Сервер, получив запрос, выполняет действия и посылает ответ.

Сервер может иметь множество клиентов в одно и то же время и клиент может запрашивать данные от множества серверов. Более того, приложение может быть одновременно и клиентом и сервером.

Технология DDE изначально создавалась для организации обмена данными между приложениями, выполняющимися на одной машине, но существует и развитие этой технологии для приложений, выполняющихся на разных машинах, называемое NetDDE.

Технология DDE зародилась в недрах операционных сред, управляемых событиями.

Операционная среда, управляемая событиями, отслеживает все возможные события, происходящие в системе, например, нажатия клавиш, перемещения мыши, сигналы от внешней среды, прием сообщений от приложений.

Обрабатывая эти события, операционная среда формирует сообщения приложениям.

Приложение, которое выполняется в среде, управляемой событиями, находится в бесконечном цикле и проверяет наличие сообщений ему от операционной среды. В соответствие с характером принимаемых сообщений приложение выполняет требуемые действия и снова посылает сообщения среде.

С учетом указанной особенности, в развитии технологии DDE можно выделить три этапа.

1) Первый этап существования DDE, когда DDE реализовывался на основе прямого обмена системными сообщениями между приложениями.

Для посылки сообщений могут быть использованы системные функции SendMessage() (синхронная) и PostMessage() (асинхронная).

Для DDE выделена специальная группа сообщений, а именно:

1. wm_DDE_Initiate - Инициировать сеанс обмена данными;

2. wm_DDE_Terminate - Завершить сеанс обмена данными;

3. wm_DDE_Execute - Выполнить команду;

4. wm_DDE_Ack - Получить статус операции;

5. wm_DDE_Poke - Послать данные серверу;

6. wm_DDE_Request - Запросить данные у сервера;

7. wm_DDE_Advise - Установить связь с сервером;

8. wm_DDE_UnAdvise - Завершить связь с сервером;

9. wm_DDE_Data - Послать данные клиенту.

Программирование обмена по данной технологии является довольно сложной задачей, что сдерживало распространение технологии DDE. Поэтому для создания приложений, реализующих DDE, была создана специализированная объектно-ориентированная библиотека DDEML, являющаяся надстройкой над DDE и предоставляющая API, облегчающий создание DDE-приложений.

Вместо непосредственной посылки DDE-сообщений с помощью функций SendMessage() и PostMessage() приложения используют функции DDEML.

2) Второй этап существования DDE, когда DDE-приложения программируются с помощью DDEML.

Этот этап далее будет рассмотрен более подробно. Отметим только, что с появлением DDEML сложность создания DDE-приложений уменьшилась, но все равно оставалась еще довольно сложной.

3) Третий этап существования DDE можно связать с появлением визуальных средств разработки приложений. Так, например, среда Delphi предлагает законченные компоненты DDE-клиента и DDE-сервера, которые скрывают в себе все формализуемые этапы функционирования DDE-приложений, и существенно облегчают создание DDE-приложений.

Не смотря на развитие DDE-технологии в соответствие с перечисленными тремя этапами, существуют некоторые общие концепции в нее заложенные, остающиеся неизменными.

К знакомству с этими концепциями мы и перейдем.

Система адресации данных

DDE-протокол использует трехуровневую систему адресации передаваемых данных:

Service Name - имя сервиса. Самый верхний уровень адресации. Серверы могут реализовывать несколько видов сервиса, однако чаще всего один сервер реализует один вид сервиса, поэтому в качестве имени сервиса может быть использовано имя приложения - Application.

Topic Name - имя темы, определяющее некоторый логический контекст данных. Для серверов, работающих на основе файловых документов, имя темы чаще всего совпадает с именем файла документа.

Item Name - имя элемента данных. Имя элемента идентифицирует элемент данных, который может быть передан за одну транзакцию.

Транзакцией будем называть событие передачи одного элемента данных от клиента к серверу или от сервера к клиенту.

Все три уровня описываются строками. Строки хранятся в специальной глобальной таблице. Ссылки на соответствующие строки называются атомами.

Обмен конкретными значениями данных всегда сопровождается указанием (явным или неявным) всех трех уровней, к которым относятся передаваемые данные.

Концепция функции отклика

Мы уже знакомились с понятием процедуры-обработчика сообщений, т.е. процедуры, которую вызывает среда в качестве реакции на принятое сообщение.

Функция отклика в DDE - это и есть такая процедура-обработчик. Ее еще называют процедурой обратного вызова. Отличие от ранее рассмотренных вариантов состоит в большей сложности.

DDE-приложение определяет функцию отклика, которую будет вызывать DDEML в ответ на события, возникающие при создании соединения между приложениями, при обмене данными и при разъединении. DDEML передает в эту функцию номер транзакции, а функция по этому номеру выполняет запрограммированные действия.

Ниже представлена примерная структура функции отклика:

Function CallBackProc(CallType : Word;

Fmt : Word;

Conv : HConv;

HSz1 : HSZ;

HSz2 : HSZ;

Data : HDDEData) : HDDEData;

Begin

CallBackProc := 0;

Case CallType Of

xtyp_... : Begin

реакция на соответствующую транзакцию

End;

Else

End Case;

End CallBackProc;

Где

CallType - тип транзакции;

Fmt -формат данных, аналогичный форматам данных Clipboard;

Сonv - ссылка на канал;

HSz1 - ссылка на строку; это или пара (Сервис, Тема) или

HSz2 - ссылка на строку; пара (Тема, Элемент)

Data - ссылка на передаваемые или принимаемые данные.

Этапы функционирования DDE-приложения

Действия, которые выполняет DDE-приложение в течение своего жизненного цикла, различаются в зависимости от того, является это приложение сервером или клиентом. Поэтому этапы функционирования DDE-сервера и DDE-клиента рассмотрим раздельно.

Инициализация сервера

Инициализация сервера включает в себя следующие этапы:

1) Регистрация функции отклика в среде. Это делается с помощью системной функции, имеющей следующее имя:

MakeProcInstance(...).

Функции MakeProcInstance передается адрес функции отклика, а она возвращает зарегистрированный указатель на функцию отклика.

В дальнейшем к функции отклика можно обращаться только через этот зарегистрированный указатель.

2) Регистрация сервера в DDEML. Это делается с помощью функции DDEML, имеющей следующее имя:

DDEInitialize(...).

Функции DDEInitialize передается зарегистрированный указатель на функцию отклика, а возвращает она идентификатор приложения как DDE-приложения и код ошибки регистрации.

3) Регистрация "сервиса", предоставляемого сервером. Это делается с помощью функции DDEML, имеющей следующее имя:

DDENameService(...).

Функции DDENameService передаются идентификатор DDE-приложения и строка с именем сервиса, а сама функция возвращает код ошибки регистрации.

После выполнения перечисленных этапов инициализация сервера заканчивается, и он переходит в режим ожидания запросов от клиентов.

Инициализация клиента

Инициализация клиента включает в себя следующие этапы:

1. Регистрация функции отклика в среде. Это делается аналогично регистрации функции отклика сервера.

2. Регистрация клиента в DDEML. Это также делается аналогично регистрации сервера.

3. Создание канала связи между клиентом и сервером.

Создание канала выполняется только по инициативе клиента и осуществляется с помощью вызова функции, имеющей следующее имя:

DDEConnect(...).

Функции DDEConnect передаются строки с именами сервиса и темы, а также зарегистрированный идентификатор DDE-клиента.

В случае успешного выполнения функция возвращает приложению-клиенту ссылку на созданный канал связи.

Этапом создания канала заканчивается инициализация клиента и появляется возможность обмена данными между клиентом и сервером.

Этапы инициализации сервера, перечисленные выше, выполняются без какого-либо участия со стороны клиента, клиент даже может быть вообще не загружен.

Последний этап инициализации клиента - создание канала связи - выполняется при участии сервера.

Создание канала - сложная процедура, включающая следующую последовательность действий.

При вызове клиентом функции DDEConnect, DDEML посылает транзакцию xtyp_Connect всем серверам, зарегистрировавшим требуемый сервис.

Функция отклика каждого сервера, в качестве реакции на эту транзакцию, проверяет у себя возможность поддержки заданных сервиса и темы, и если сервер поддерживает их, то он возвращает в DDEML соответствующий признак (1) при завершении выполнения функции отклика. Это означает, что канал между клиентом и сервером может быть создан.

Получив ожидаемый признак от функции отклика сервера, DDEML завершает выполнение функции DDEConnect клиента, возвращая ему идентификатор канала.

При этом DDEML передает серверу новую транзакцию xtyp_Connect_Confirm и идентификатор созданного канала путем повторного вызова его функции отклика.

Таким образом, и клиент и сервер получают идентификатор одного и того же канала, после чего соединение считается установленным и появляется возможность обмена данными.

Обмен данными

Три варианта обмена данными могут быть реализованы с помощью DDE-технологии.

1. Передача данных от сервера к клиенту по запросу последнего.

2. Передача данных от клиента серверу.

3. Передача данных от сервера к клиенту без запроса от последнего при изменениях данных.

Все действия по обмену данными со стороны клиента выполняются с помощью функции

DDEClientTransaction(...).

Этой функции передаются: идентификатор канала, тип транзакции и другие данные, определяемые этим типом. Например, имя элемента, формат данных, адрес данных.

Передача данных от сервера по запросу от клиента

Для получения данных от сервера по запросу, клиент вызывает функцию DDEClientTransaction, посылая транзакцию xtyp_Request в DDEML.

В случае успешного завершения транзакции, функция возвращает ссылку на запрашиваемые данные, находящиеся в области глобальной памяти. Эти данные должны быть прочитаны клиентом в локальную память с помощью вызова функции

DDEGetData(...),

которой передаются ссылка на глобальную память, содержащую данные, и указатель на буфер в локальной памяти.

Посмотрим теперь, как реагирует на транзакцию xtyp_Request сервер.

DDEML передает эту транзакцию серверу, вызывая его функцию отклика. Кроме типа транзакции, DDEML передает серверу формат данных и имена темы и элемента.

Если сервер поддерживает запрашиваемые формат, тему и элемент, то он в вызове функции отклика возвращает ссылку на требуемые данные.

Эта ссылка формируется при вызове функции

DDECreateDataHandle(...),

которая запрашивает блок глобальной памяти и переписывает в него данные из локального буфера.

Передача данных от клиента серверу

Клиент посылает данные серверу, используя транзакцию xtyp_Poke в вызове функции DDEClientTransaction. В эту функцию также передаются имя темы, имя элемента, формат данных и адрес данных.

DDEML передает транзакцию серверу, вызывая его функцию отклика и указывая имя темы, имя элемента, формат данных и адрес данных.

Данные прочитываются сервером с помощью функции DDEGetData. В случае успешного завершения операции сервер обязан возвратить в DDEML подтверждение, возвращая при выходе из функции отклика значение DDE_FAck.

Передача данных от сервера без запроса от клиента

Если клиенту необходимо постоянно следить за изменениями данных, он может создать advise loop - извещающий канал.

Извещающий канал может быть создан двух типов:

1. теплый канал, в котором при изменении данных сервер посылает клиенту извещение о том, что данные изменились, а клиент, приняв извещение, посылает серверу запрос на получение данных. Далее клиент и сервер функционируют по алгоритму обмена данных по запросу от клиента.

2. горячий канал, когда при изменениях данных сервер сразу же передает их клиенту без предварительного извещения.

Три рассматриваемых алгоритма передачи данных, а именно:

1. передача данных по запросу от клиента;

2. передача по теплому каналу;

3. передача по горячему каналу,

различаются повышением нагрузки на канал. С этой точки зрения наиболее предпочтительным следует считать первый алгоритм, а наименее предпочтительным - третий.

Рассмотрим пример функционирования горячего извещающего канала.

Горячий извещающий канал создается по инициативе клиента путем передачи транзакции xtyp_AdvStart в вызове функции DDEClientTransaction.

Эта транзакция передается серверу путем вызова его функции отклика.

Если сервер поддерживает создание извещающего канала, то при каждых изменениях данных он должен теперь вызывать функцию

DDEPostAdvise(...),

которой передаются имена темы и элемента, описывающие изменившиеся данные.

Вызов функции DDEPostAdvise приводит к тому, что DDEML посылает транзакцию xtyp_AdvReq серверу. Функция отклика сервера возвращает ссылку на измененные данные таким же способом, как сервер делал при реакции на транзакцию xtyp_Request, т.е., вызывая функцию DDECreateDataHandle.

Получив ссылку на данные, DDEML посылает транзакцию xtyp_Advdata клиенту, передавая ему эту ссылку. Клиент прочитывает данные в своей функции отклика с помощью функции DDEGetData. При выходе из функции отклика, в случае успешного прочтения данных, клиент должен вернуть DDE_FAck в DDEML.

Закрытие извещающего канала производится по инициативе клиента передачей транзакции xtyp_AdvStop в DDEML.

Сервер, получив эту транзакцию, должен предусмотреть отказ от последующих вызовов функции DDEPostAdvise при изменениях данных.

Разрыв соединения

Разрыв соединения может быть произведен как по инициативе клиента, так и по инициативе сервера.

Разрыв соединения производится вызовом функции

DDEDisconnect(...),

которой передается идентификатор разрываемого канала.

В ответ на этот вызов DDEML передает транзакцию xtyp_Disconnect партнеру по связи.

Действия по завершению соединения включают в себя, как правило, освобождение динамической памяти, выделяемой под буфера данных и под строки, описывающие имена сервиса, темы и элементов.

Кроме того, приложения - бывшие партнеры по связи должны вызвать функцию

DDEUninitialize(),

освобождающую ресурсы DDEML, связанные с соответствующими приложениями.

И, наконец, вызывается процедура

FreeProcInstance(),

разрушающая связь функции отклика приложения со средой, в которой оно функционирует.

Перечисленные действия являются минимальным набором действий, реализующих пару клиент-сервер.

Как видно, даже этот минимальный набор действий является достаточно сложным. Поэтому современные среды разработки программ стремятся облегчить проектирование DDE-приложений. В качестве примера такого стремления рассмотрим принципы создания DDE-приложений в среде Delphi.

Организация обмена данными по протоколу DDE между Delphi-приложениями

В Delphi-среде приложения DDE-сервер и DDE-клиент создаются путем включения в форму специализированных невизуальных компонентов:

1. компоненты TDDEServerConv и TDDEServerItem включаются в приложение-сервер;

2. компоненты TDDEClientConv и TDDEClientItem включаются в приложение-клиент.

Соответствующая настройка свойств компонентов на этапе проектирования приложений обеспечивает взаимодействие приложений при их выполнении.

Рассмотрим последовательно этапы создания DDE-сервера и DDE-клиента в среде Delphi.

Создание DDE-сервера

1. Компоненты DDEServerConv и TDDEServerItem помещаются в форму. Среда проектирования автоматически присваивает компонентам имена:

DDEServerConv1 и DDEServerItem1.

2. Производится связывание компонентов DDEServerConv1 и DDEServerItem1 путем присваивания свойству ServerConv компонента TDDEServerItem значения, равного имени компонента TDDEServerConv

- DDEServerConv1.

Данное присваивание позволяет связать компоненты только во время проектирования приложения, но для того, чтобы они оказались связанными и во время выполнения, необходимо в инициализационной части приложения сделать явное присваивание:

DDEServerItem1.ServerConv := DDEServerConv1;

3. Система трехуровневой адресации данных выглядит следующим образом:

1. имя сервиса - имя исполняемого файла приложения-сервера, или имя проекта без расширения;

2. имя темы - имя компонента TDDEServerConv - DDEServerConv1.

3. имя элемента - имя компонента TDDEServerItem - DDEServerItem1.

4. Данные содержатся в свойстве Text компонента TDDEServerItem.

Чтобы передать данные, предназначенные для клиентов, например, из компонента TEdit - строки ввода - в компонент TDDEServerItem, необходимо выполнить присваивание:

DDEServerItem1.Text := Edit1.Text;

где Edit1 - имя компонента TEdit, включенного в форму приложения-сервера для отображения данных.

Данный текст должен быть включен в обработчик события OnChange компонента TEdit.

Если клиент передал данные серверу с помощью метода PokeData, то принятые сервером данные могут быть отображены, например, в строке редактирования следующим образом:

Edit1.Text := DDEServerItem1.Text,

Данный текст должен быть написан в обработчике события OnPokeData компонента TDDEServerItem.

Создание DDE-клиента

1. Компоненты TDDEClientConv и TDDEClienItem помещаются в форму. Среда проектирования автоматически присваивает им имена:

DDEClientConv1 и DDEClientItem1.

2. Производится связывание компонентов DDEClientConv1 и DDEClientItem1 путем присваивания свойству DDEConv компонента TDDEClientItem значения, равного имени компонента TDDEClientConv - DDEClientConv1.

Данное присваивание позволяет связать компоненты только во время проектирования приложения, но для того, чтобы они оказались связанными и во время выполнения, необходимо в инициализационной части приложения сделать явное присваивание:

DDEClientItem1.DDEConv := DDEClientConv1;

3. Производится присвоение имен сервиса, темы и элемента соответствующим свойствам компонентов клиента:

1. свойству DDEService компонента TDDEClientConv присваивается значение, равное имени проекта сервера;

2. свойству DDETopic компонента TDDEClientConv присваивается значение, равное имени компонента TDDEServerConv сервера;

3. свойству DDEItem компонента TDDEClientItem присваивается значение, равное имени компонента TDDEServerItem сервера.

4. Если свойству ConnectMode компонента TDDEClientConv присвоить значение ddeAutomatic, а свойству ServiceApplication компонента TDDEClientConv присвоить значение, равное полному (с учетом пути) имени программы сервера, то приложение сервер будет загружаться и устанавливать соединение с клиентом автоматически при загрузке последнего.

Со стороны клиента соединение устанавливается вызовом метода

SetLink,

которому передаются строки с именами сервиса и темы.

5. Запрос данных от сервера выполняется путем вызова метода

DDEClientConv1.RequestData(DDEClientItem1.DDEItem)

компонента TDDEClientConv, передавая при этом данному методу имя запрашиваемого элемента данных. Данный метод возвращает указатель на ASCIIZ-строку, содержащую данные.

6. Передача данных от клиента серверу выполняется путем вызова метода

DDEClientConv1.PokeData(...),

которому передаются имя элемента данных и указатель на ASCIIZ-строкe, содержащую передаваемые данные.

7. Сами данные содержатся в свойстве Text компонента TDDEClientItem и обновляются вместе с данными сервера.

Данные могут выводиться в строку редактирования Edit1 типа TEdit с помощью присваивания:

Edit1.Text := DDEClientItem1.Text;

Указанная строка должна быть включена в обработчик события OnChange компонента TDDClientItem.

8. Разрыв соединения выполняется по инициативе клиента методом CloseLink компонента TDDEClientConv.

Как видно из приведенного описания, визуальная среда проектирования избавляет разработчика от массы рутинных процедур по установлению взаимодействия между DDE-приложениями, сводя их к выбору подходящих свойств специализированных компонентов и написанию кодов, описывающих реакции компонентов на изменения этих свойств во время выполнения программы.

6.3.5. Обмен данными по технологии OLE