OpenOffice + Delphi
OpenOffice.org ведет свое происхождение от офисного пакета StarOffice, разработанного немецкой фирмой StarDivision в середине 90-х годов. Осенью 1999 года корпорация Sun купила StarDivision. В июне 2000 года, уже под торговой маркой SUN вышел StarOffice 5.2 под MS Windows, Linux и Solaris. 13 октября 2000 года были открыты исходные тексты StarOffice (за исключение кода некоторых модулей, разработанных третьими фирмами), и этот день официально считается днем рождения OpenOffice.org. В настоящее время над кодом OpenOffice.org работают как добровольцы со всего света, так и программисты корпорации SUN. Sun Microsystems, Inc в основном и финансирует деятельность проекта OpenOffice.org. В настоящее время из одного исходного кода, разрабатываемого сообществом OpenOffice.org выпускаются два продукта: StarOffice, в который добавляются компоненты под проприетарной лицензией и свободный OpenOffice.org. В настоящее время в OpenOffice.org большинство проприетарных компонентов, присутствующих в StarOffice заменено их свободными аналогами. Все более широкие массы компьютерной общественности обращают свой взор на офисный пакет OpenOffice.org. Вслед, за обыкновеннными пользователями пришел черед и программистов, волею судеб вынужденных работать с новым детищем. Коллег наших можно разделить на три условных группы: первая и самая многочисленная - люди, писавшие под Visual Basic; вторая - программисты Java, и третья, инструментом представителей которой являются Delphi, C Builder, VC++ etc. Почему именно такая градация? С первыми все очевидно. офисный пакет от Майкрософт в качестве языка использует VBA, а переход на новый продукт редко когда начинается с нуля. То есть главной задачей этой группы является адаптация имеющихся кодов под OpenOffice.org. Со второй группой, тоже все более-менее понятно - компонентная модель OpenOffice.org заточена под Java. Более того, одним из трех приоритетных языков, поддерживаемых разработчиками, является Java. В состав приоритетных, кроме Java входят C++ и StarBasic (аналог VBA от Майкрософта). Третья группа перспективной разработчиками не считается (далее речь будет идти сугубо о Delphi). А жаль, потому как использование СОМ-связки с офисными пакетами один из очень расспростаненных приемов. Достаточно вспомнить хотя бы составление отчетов, с целью их дальнейшей модификации или передачи третьим лицам, а про использование встроенной проверки орфографии я вообще молчу. Обидно другое. Я давно пользуюсь девизом: "Документация как секс - лучше любая, чем никакой". Но извините, меня очень огорчил тот факт, что в составе 94-мегабайтного набора инструментов разработчика (OpenOffice.org Software Development Kit), который мне пришлось выкачать (правда в архиве это в 2 раза меньше. :)) есть единственный рабочий пример связки OpenOffice.org-Delphi и к тому же не рабочий. Этого, при всем уважении к разработчикам, я понять не могу. Если уж вы игнорируете среду разработки, то будьте добры, до блеска отдрайте единственный пример. Ну да ладно, это все эмоции. После ручной доработки код из примера заработал. Прямо как в известном анекдоте. Украли "шпиены" чертежи страшного советского самолета (допустим СУ-24 :)) и передали своим техникам. Те собирают - паровоз получается и хоть ты тресни. И тут главный "шпиен" внизу страницы маленькую сносочку обнаруживает: "После сборки тщательно обработать напильником". Слюни в жилетку пускать рано. В том же SDK есть масса рабочих примеров на Visual Basic, Java и C++. Так что скажем слова благодарности разработчикам, что не дают они расслабиться нашему пытливому уму. Однако, уважаемый читатель, если автоматизацию офиса ты собираешься проводить только с помощью Delphi и не более, хочу предостеречь тебя от безсмысленной траты трафика. Отдельные статьи и примеры кода имеются в интернете. Компонентая модель OpenOffice.org Работа StarOffice.org базируется на компонентной модели, именуемой Универсальные Сетевые Объекты (Universal Network Objects, UNO). UNO предоставляет механизм для кроссплафторменного и языконезависимого программирования. Как я уже отмечал, основное внимание уделяется аспектам работы с Java, C++ и StarOffice Basic. Оно и понятно, ведь во главу угла ставиться кроссплатформенность. Более того, пальму первенства держат даже такие экзотические языки как JavaScript и PHP. Но странно как-то, по крайней мере для меня, будет выглядеть эта связка. Начиная с версии Старофис 5.2, автоматизация OLE является составной частью пакета. Однако, прямой доступ к этим компонентам (UNO) из Delphi получить не удастся. Для этого используется механизм "моста автоматизации" (Automation Bridge), который объединяет интерфейс автоматизации OLE с языковыми связками StarOffice API. UNO предоставляет единственный интерфейс для работы со своими компонентами - Сервис Менеджер (Service Manager). Сервис Менеджер по сути является фабрикой классов, следовательно возвращает интерфейс IClassFactory. С точки зрения концепции модели UNO иного пути для создания объектов автоматизации StarOffice.org как через Сервис Менеджер нету. UNO изначально не создавался с поддержкой автоматизации и COM, а был ориентирован на работу со скриптовыми языками. По материалам "http://developers.sun.com/techtopics/desktop/reference/techart/staroffice_sdk.html" Сервис Менеджер Исполняемый код СМ содержится в файле soffice.exe. Этот исполняемый файл держит все СОМ подключения и открытые документы, будь-то текстовые либо электронные таблицы. Даже в случае насильственного повторного запуска, запущенный процесс берет на себя всю заботу об открытии документов, предоставлении интерфейсов OLE автоматизации, а копию закрывает. Поэтому в памяти может находится только один такой процесс. А это значит, что для связки OO-Delphi нету понятия подключения к существующему СОМ объекту, то есть GetActiveObject имеет тот результат что и вызов CreateOleObject. Поэтому, дабы избежать ненужной проверки на существование запущенного процесса, будем использовать второй вариант, что неизбежно приведет нас к нужному результату. СМ, так же как и объекты, которые он создает, и объекты, предоставляемые им же косвенно через результаты возврата функций, является типичным объектом автоматизации. Имеется возможность удаленного доступа через механизм DCOM. Сервис Менеджер базируется на Сервис Менеджере UNO и ничем не отличается от обычных компонентов UNO. "Как же так?" - спросите вы, "Ведь было сказано, что UNO не поддерживает СОМ". И будете совершенно правы, за конвертацию Сервис Менеджера отвечает сервис 'com.sun.star.bridge.OleBridgeSupplier2' . Результирующий объект автоматизации содержит в себе объект UNO и транслирует вызовы IDispatch.Invoke в необходимые функции интерфейсов UNO. Возвращаемые после таких вызовов объекты, тоже автоматически конвертируются в правильные СОМ-объекты. Развернутую статью по сервисам конвертации оставлю на потом. Однако замечу, что материал интересен, как минимум, с теоретической точки зрения. Подытожу. Схема взаемодействия такова: СервисМенеджер - ОО Десктоп - Документы (открытые либо созданные). По мат. " http://api.openoffice.org/docs/DevelopersGuide/ProfUNO/ProfUNO.htm#1+4+4+Automation+Bridge" Практика unit SampleCode; Заключение К сожалению, как я уже писал, документации по связке ОО+Delphi практически нету. Максимум, это примеры сродни этому. Однако, есть много примеров для других языков. И если вам не чужды понятия мозговой деятельности, милости прошу. Начать рекоммендую с форума разработчиков. Особо следует обратить внимание на раздел с примерами. Отдельно хочу выразить благодарность Роману Игнатьеву (Romkin©) и Юрию Федорову© за потраченное время. На сегодня все, надеюсь на продолжение. Все в ваших руках - пишите отзывы.
Страница сайта http://silicontaiga.ru
Оригинал находится по адресу http://silicontaiga.ru/home.asp?artId=5609 |