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 її доведеться перервати через помилки, то запущений об'єкт залишиться "висіти", і його доведеться видаляти за списку запущених додатків системними засобами (через
Після того як ви створили 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.