Составители:
Командные транзакции позволяют клиенту посылать серверу команды или после-
довательности команд, заставляющих его выполнять определенные действия.
Обмен данными начинается в тот момент, когда приложение-клиент инициирует
диалог и получает ответ от сервера. Установив соединение, клиент и сервер обменива-
ются данными вплоть до того момента, пока диалог не будет прерван по инициативе од-
ной из сторон. Обмен данными осуществляется одним или сразу несколькими из пере-
численных способов [6]:
• клиент запрашивает данные, а сервер отвечает на запрос;
• клиент просит проинформировать его, произошли ли изменения определенных дан-
ных;
• клиент просит автоматически передать определенные элементы данных в случае их
обновления;
• клиент посылает команду, а сервер ее выполняет;
• клиент посылает серверу незапрашиваемый элемент данных.
Важно помнить о том, что приложение-клиент может также выступать в роли сер-
вера и наоборот. Любое приложение может одновременно быть и сервером, и клиентом.
Различия между клиентом и сервером являются весьма искусственными и не вполне оп-
ределенными, поскольку любой из них может как запрашивать, так и передавать данные.
8.4.2. API-функции библиотеки DDEML
В своей основе DDE-диалог - это довольно сложный и запутанный процесс, вклю-
чающий многочисленные ответы и подтверждения с применением разных протоколов.
Поэтому, для облегчения жизни программистов, создана специальная библиотека -
DDEML (DDE Management Library).
DDEML входит в состав Windows и содержит высокоуровневые API-функции, по-
зволяющие упростить процесс DDE-диалога. Библиотека поддерживает запись о каж-
дом диалоге с помощью структуры CONVINFO, которая содержит информацию об уча-
стниках, установивших диалог, о запрашиваемых темах и элементах, об используемых
форматах и типах данных, а также о статусе диалога, ошибках и т.д. Следует отметить,
что большинство элементов этой структуры можно просто проигнорировать, возложив
все обязанности по ведению записей на DDEML. Рассмотрим основные функции данной
библиотеки.
Функция DdeInitialize предназначена для задания функции обратного вызова,
управляющей графиком DDE-сообщений. Когда приложение вызывает функцию
DdeInitialize, DDEML уведомляет об этом другие программы, отправляя сообщение
XTYP_REGISTER их функциям обратного вызова. Эти сообщения используются мно-
гими клиентами для поддержки списка доступных сервисов.
Необходимость указывать идентификатор экземпляра приложения при вызове
функции DdeInitialize представляет собой дополнительное ограничение для программи-
стов, работающих в среде Windows, поскольку этот идентификатор является локальным
для потока и не наследуется дочерними процессами. А так как идентификатор экземпля-
ра необходимо задавать в качестве параметра большинства DDEML-операций, соответ-
ствующие операции должны находиться в том же самом потоке, в котором был осуще-
ствлен вызов функции DdeInitialize. Поток, инициализировавший DDE-сеанс, не должен
прекращаться вплоть до его завершения; в противном случае вы не сможете вызвать
функцию DdeUninitialize, осуществляющую корректное завершение сеанса.
После инициализации сервер должен зарегистрировать имена предлагаемых серви-
сов. Для этой цели служит функция DdeNameService, которая вызывается с указанием
дескриптора строки, содержащей имя сервиса, и идентификатора экземпляра данного
203
Командные транзакции позволяют клиенту посылать серверу команды или после- довательности команд, заставляющих его выполнять определенные действия. Обмен данными начинается в тот момент, когда приложение-клиент инициирует диалог и получает ответ от сервера. Установив соединение, клиент и сервер обменива- ются данными вплоть до того момента, пока диалог не будет прерван по инициативе од- ной из сторон. Обмен данными осуществляется одним или сразу несколькими из пере- численных способов [6]: • клиент запрашивает данные, а сервер отвечает на запрос; • клиент просит проинформировать его, произошли ли изменения определенных дан- ных; • клиент просит автоматически передать определенные элементы данных в случае их обновления; • клиент посылает команду, а сервер ее выполняет; • клиент посылает серверу незапрашиваемый элемент данных. Важно помнить о том, что приложение-клиент может также выступать в роли сер- вера и наоборот. Любое приложение может одновременно быть и сервером, и клиентом. Различия между клиентом и сервером являются весьма искусственными и не вполне оп- ределенными, поскольку любой из них может как запрашивать, так и передавать данные. 8.4.2. API-функции библиотеки DDEML В своей основе DDE-диалог - это довольно сложный и запутанный процесс, вклю- чающий многочисленные ответы и подтверждения с применением разных протоколов. Поэтому, для облегчения жизни программистов, создана специальная библиотека - DDEML (DDE Management Library). DDEML входит в состав Windows и содержит высокоуровневые API-функции, по- зволяющие упростить процесс DDE-диалога. Библиотека поддерживает запись о каж- дом диалоге с помощью структуры CONVINFO, которая содержит информацию об уча- стниках, установивших диалог, о запрашиваемых темах и элементах, об используемых форматах и типах данных, а также о статусе диалога, ошибках и т.д. Следует отметить, что большинство элементов этой структуры можно просто проигнорировать, возложив все обязанности по ведению записей на DDEML. Рассмотрим основные функции данной библиотеки. Функция DdeInitialize предназначена для задания функции обратного вызова, управляющей графиком DDE-сообщений. Когда приложение вызывает функцию DdeInitialize, DDEML уведомляет об этом другие программы, отправляя сообщение XTYP_REGISTER их функциям обратного вызова. Эти сообщения используются мно- гими клиентами для поддержки списка доступных сервисов. Необходимость указывать идентификатор экземпляра приложения при вызове функции DdeInitialize представляет собой дополнительное ограничение для программи- стов, работающих в среде Windows, поскольку этот идентификатор является локальным для потока и не наследуется дочерними процессами. А так как идентификатор экземпля- ра необходимо задавать в качестве параметра большинства DDEML-операций, соответ- ствующие операции должны находиться в том же самом потоке, в котором был осуще- ствлен вызов функции DdeInitialize. Поток, инициализировавший DDE-сеанс, не должен прекращаться вплоть до его завершения; в противном случае вы не сможете вызвать функцию DdeUninitialize, осуществляющую корректное завершение сеанса. После инициализации сервер должен зарегистрировать имена предлагаемых серви- сов. Для этой цели служит функция DdeNameService, которая вызывается с указанием дескриптора строки, содержащей имя сервиса, и идентификатора экземпляра данного 203
Страницы
- « первая
- ‹ предыдущая
- …
- 199
- 200
- 201
- 202
- 203
- …
- следующая ›
- последняя »