Реферат: Программирование в LE-технология Microsoft Windows

Обычно, когда приложение, создающее идентификатор данных, передает его 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 в термин объект вкладывается несколько специфический смысл. Пользователя не приглашают постигать азы ООП, или заняться конструированием объектов на С++.

Когда об объектах говорят в рамках Windows, то имеют в виду возможность встраивания в некоторый документ фрагмента, порожденного другим приложением. Вот это "инородное тело" и называется объектом.

В таком подходе нет ничего нового. Когда в текст, подготавливаемый Write, вставляется рисунок из Paintbrush посредством Clipboard или таблиц Exсel, в документ, подготавливаемый в Word, то результатом действия будет как раз появления объекта.

Традиционные объекты всегда представляют собой копии. Работа с ними основывается на том, что все Windows приложения поддерживают не только свой собственный формат, но и некоторый обобщенный, стандартный, играющий роль общеизвестного международного языка. Если, например, в текстовый документ вставляется таблица из табличного процессора, то буфер промежуточного обмена преобразует ее в формат к стандартному, и тем самым обеспечивает вставку. Такая копия в текстовом редакторе по виду не отличается от оригиналу, но она недоступна для внесения изменений. Невозможно, вставив таким способом копию из Paintbrush в Write документ, изменить цвет, толщину линий или масштаб.

Новые объекты, доступные в рамках Windows 3.1 очень похожи на традиционные, но они не являются копиями - это оригиналы. Они имеются в единственном экземпляре и находятся непостредственно в целевых документах. Там они существуют одновременно в двух форматах - в стандартном и в формате приложения-источника.

Благодаря стандартному формату объект может индицироваться и сохранять в рамках целевого документа. Имеется возможность обработки объекта также, как и любого файла оригинала. Ситуация выглядит так, словно внутри объекта встроен другой. Это обеспечивает доступ к средствам обработки нового объекта (приложению-источнику) посредством простого двойного щелчка на объекте.

Встроенные объекты

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

Встроенные объекты существуют только в единственном экземпляре и только там, где они встроены - в целевом документе. Обрабатываются они своими "родительскими" программами, вызываемыми весьма эффективным способом, в отличие от традиционного.

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

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

Важным достоинством подобного связывания встроенных объектов является мобильность документов. Можно легко перенести такой документ с одной машины на другую (необходимо только чтобы на них обеих была установлена оболочка и были необходимые приложения или динамические библиотеки от них). Для обработки встроенных объектов достаточно будет щелкнуть по ней дважды и на другой машине произойдет тоже самое, что и на вашей: вызовется соответствующее приложение. В этом случае необходимым условием переноса является наличие на другой машине текстового редактора Write и графического редактора Paintbrush.

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

Перспективы развития OLE

Технология OLE делает только первые шаги. Пока только некоторые Windows приложения являются OLE совместимыми. Среди утилит группы Accessories версии 3.1 такими на сегодняшний день являются только Write, Paintbrush и Cardfile. Но даже они "в своем кругу" не допускают вставки в произвольном направлении (т.е. из любой в любую другую). В настающее время речь идет о поддержке наиболее оправданного с практической точки зрения "направления встраивания" - из Paintbrush в Write и Сardfile документа.

Чтобы определить какие из приложений поддерживаю OLE интерфейс, необходимо из OLE-совместимого приложения выполнить директиву "ВСТАВИТЬ ОБЪЕКТ" в меню "Edit". В отрывшемся окне будет продемонстрирован список доступных встраиваемых объектов.

В настоящий момент многие компиляторы уже ввели поддержку OLE в свои библиотеки: Borland C++ ver4.5. Пример использования OLE технологии приведен в приложении 1. Данная программа использует созданный рисунок Paintbrush в виде файла или копирует его из Clipboard.

Заключение

В заключении хотелось бы отметить, что существующие способы обмена информации возникали вместе с развитием Windows. Как сама суть Windows, они являются продолжением заложенной в нее цель: cспособность работать с файлами любых форматов, на любом оборудовании. В отличие от стандартного решения, когда фирма-производитель оболочки (типа Windows) пыталась сама написать различные драйверы для поддержки устройств и различные библиотеки для поддержки форматов многочисленных файлов других пакетов, фирма Microsoft возложила эту обязанность на производителей оборудования и программного обеспечения. Таким образом, последовательное развитие Clipboard-->DDE-->OLE является продолжением воплощения идеи "сам изобрел - сам внедряй". Естесственно, наибольшие надежды сейчас возлагаются на OLE (ее новый стандарт OLE.2), так как этот стандарт позволяет включать в себя очень мощные средства, такие как Multimedia. В одном файле может находится не только текст, рисунок, а и даже целый фильм, полностью озвученный и готовый к показу.

Список литературы

1. Гладков С.А. Фролов Г.В. Программирование в Microsoft Windows: В 2-х частях. М.:"ДИАЛОГ-МИФИ", 1992.

2. Фойц С. Windows 3.1 для пользователя. Пер. с немецкого Киев:BHV, 1992.

3. Microsoft Windows Software Development Kit. Version 3. Programmer's Reference, Programming Tools, Windows Extensions.

4. Charles Petzold. Programming Windows. Microsoft Press.

5 Borland C++. Usres manual.