Главная » Delphi » Технология OLE Automation

0

OLE означает Object Linking and Embedding (связывание и внедрение объектов). OLE Automation — это часть технологии OLE, которая отвечает за интеграцию приложений (см. мечты Джефа Раскина в главе I). СОМ — это не то, что СОМ-порт, а вовсе даже Component Object Model. Разница между OLE Automation и СОМ в том, что вторая появилась позднее и является более продвинутой версией, позволяющей, в том числе, взаимодействующим приложениям находиться на разных компьютерах. Для простоты будем считать, что для наших задач между ними никакой разницы нет. Модуль, отвечающий за объекты OLE Automation, в Delphi носит говорящее название ComObj. Мы будем говорить OLE, подразумевая OLE Automation, а термин "СОМ" мы с этого момента вообще вслух постараемся не произносить, чтобы не путаться.

Кстати, ActiveX из той же серии, только компоненты ActiveX обычно представляют собой специально сделанные программки (альтернативу Java). Из компонентов ActiveX фактически "слеплен" Internet Explorer, наш любимый WebBrowser есть не что иное, как вызов этих компонентов. Компоненты ActiveX мы в этой книге не рассматриваем, во-первых, потому что с ними куда проще работать через Visual Basic, во-вторых, потому что по мере возможности лучше вообще с ними не работать из-за "глючности", неповоротливости и крайней негибкости в использовании. Впрочем, OLE Automation, как мы увидим, не сильно отличается в этом смысле от компонентов ActiveX.

Заметки на полях

Хотелось бы подчеркнуть разницу между OLE/COM/ActiveX и обычным API- интерфейсом. OLE-объект — не функция или процедура, а то приложение, к которому вы обращаетесь, целиком, со всеми его достоинствами и недостатками. Мы хорошо это видели на примере неповоротливого и плохо управляемого, но в остальном вполне работоспособного WebBrowser. Поэтому прввильно поставленная задача, которую может решить технология OLE, есть встраивание некоего приложения (MS Word, MS Excel, Acrobet Reeder, Internet Explorer и т. п.) в вашу программу, или просто вызов другой программы (не функции!) для совершения неких действий. Причем, в отличие от вызовов API, это можно сделать и с удаленного компьютера через Сеть. Описаний задач подобного рода вы можете найти а Сети сколько угодно (см., например. [24]). Позже мы попробуем сделать немного иначе и выяснить, насколько можно продвинуться в использовании OLE-объектов — подобно функциям API — для выполнения процедур, которые мы сами делать не умеем, с помощью вызова приложения, которое таким умением обладает, но ствраясь сам факт вызове скрыть. Как мы увидим, это удастся нам только отчвсти.

Через OLE можно в вашем приложении сделать все, что умеет приложение, которое имеет Automation Server. Для этого нужно сделать так, чтобы ваше приложение стало Automation Container. Эти устрашающие термины не должны вас пугать — вы просто создаете у себя объект с определенным названием с помощью вызова функции Createoieobject и им манипулируете. И. главное, не забываете его потом уничтожить, причем в этом деле есть нюансы: вы, конечно, можете просто уничтожить данный объект у себя в приложении, как обычно, но он в системе от этого не исчезнет. Поэтому уничтожать его нужно дважды— сначала подходящим методом (типа Close иди Quit) самого объекта его закрывают, а потом уже уничтожают ссылку на него в вашей программе через вызов функции Unassigned, причем последнее даже необязательно (подобно тому, как необязательно уничтожать ассоциацию файловой переменной с конкретным именем файла, но обязательно его закрыть). Если же вы забудете его уничтожить, то последствия могут быть довольно печальными, причем учтите, что если при отладке программы из среды Delphi ее придется прервать из-за ошибок, то запущенный объект останется "висеть", и его придется удалять за списка запущенных приложений системными средствами (через <Ctrl>+<Alt>+<DeI>). Разумеется, при всех этих манипуляциях и само приложение, и классы его Automation Server должны быть установлены в системе, иначе ничего не выйдет.

После того как вы создали OLE-объект, про Delphi можете почти забыть. Методы и свойства объекта теперь нужно вызывать из набора его свойств, и

Delphi к этому касательства никакого иметь не будет. Причем вы не только не сможете получить привычную подсказку относительно свойства или метода, поставив точку после названия объекта — компилятор вообще не будет осуществлять проверку, что вы там такое понаписали. И даже обработку ошибок через механизм исключений try.. .except вам осуществить удастся не всегда. Это, конечно, плохо, потому что те объекты, с которыми нам придется иметь дело (объекты MS Office), имеют отвратительный механизм обработки ошибок. Однако это положение действует не всегда, а только лишь в случае "позднего связывания" объектов, на чем мы остановимся позже.

Далее мы будем говорить исключительно об объектах MS Office. Из всех задач, которые могут быть решены через OLE, вызов функций Office есть одна из самых распространенных, например, The Bat! именно таким способом осуществляет проверку орфографии. Нам проверку орфографии осуществлять не надо, мы и так грамотные, а вот прочесть текст документа в формате DOC или RTF нам бы очень хотелось. И вообще-то это может быть осуществлено, как минимум, тремя разными путями.

"Официальный" путь— воспользоваться компонентами Delphi с закладки Servers. Есть множество задач, где эти компоненты использовать удобнее — хотя бы из-за наличия проверки синтаксиса программы. Управление ими сложнее, чем просто OLE-объектом, например, методы VBA и WordBasic могут вызываться с произвольным числом параметров, а Delphi-процедуры, в которые они превращаются, — нет. Есть и другие вещи, которые к нашему случаю касательства не имеют (вроде метода Connect). На сайте Borland выложен Help по этим компонентам для пятой версии (ftp://ftp.borland.com /pub/delphi/techpubs/delphi5/d5ms97.zip), но, как обычно, бестолковый и малоинформативный.

Практически тот же самый случай— когда создать компоненты-серверы предлагается самостоятельно через импорт TLB-библиотек MS Word. Тогда также на этапе компиляции осуществляется контроль параметров и вызовов методов. Еще одно преимущество обоих этих способов, носящих еще название "раннее связывание" — создание OLE-серверов выполняется несколько быстрее, чем при динамическом обращении к ним по ходу выполнения программы ("позднее связывание"). Кроме того, при динамическом связывании будут действовать не все методы объектов. Но ведь действовать "официально" мы не любим и, раз так можно, будем делать как проще — самостоятельно.

Для позднего связывания предлагается два варианта объектов. Сначала — еще в начале 90-х годов— Microsoft создала специальный диалект своего любимого языка Basic под названием Word Basic, специально "заточенный" под программирование макросов для Word и доступа к OLE-серверам. Работа с ним достаточно проста, функций там на порядок меньше, чем в VBA, и все напоминает наш любимый Pascal — в такой же мере, в какой его напоминает сам Basic. Единственное, но очень большое "но" в этом деле заключается в том, что справку по Word Basic в наши дни получить непросто: она входила в комплект Word 6.0 и Office 95, а потом из официальных источников исчезла, осталась только упомянутая далее официальная таблица соответствия. Находится эта справка (для Word 6.0) в файле wrdbasic.hlp, и у меня он есть, но положить на диск к этой книге я его не могу, т. к. хотя и Word 6.0 давно уже не поддерживается, права на распространение я не имею. Поэтому мы сделаем так: я сейчас вам покажу, как можно действовать через Word Basic для узкой задачи чтения и преобразования файлов в формате DOC и RTF, а далее мы будем действовать "по правилам" и манипулировать с объектами через VBA.

Источник: Ревнч Ю. В.  Нестандартные приемы программирования на Delphi. — СПб.: БХВ-Петербург, 2005. — 560 е.: ил.

По теме:

  • Комментарии