Андрей Колесов,

Cтатья была опубликована на сайте http://www.compress.ru/

Несмотря на то что в названии статьи указан Office 2000, мы будем рассматривать вопросы взаимодействия на примере Word 2000. Для других приложений пакета принципы такой работы cхожи, хотя и имеются некоторые различия. Тем не менее практически все, о чем мы здесь будем рассказывать, справедливо и для Office 97, и для Word 97 (имеющиеся различия мы постараемся выделить).

Подчеркну также сразу, что вся работа будет выполняться в среде редактора VBA, в частности именно там будет выполняться запуск макрокоманд на выполнение.

Постановка задачи выглядит следующим образом. Создайте документ Word с именем DocSub.doc. Теперь в среде VBA включите в его программный проект модуль кода (SubModule) и создайте в нем две простые процедуры:

Обратите внимание, что первая процедура автоматически попала в список макрокоманд проекта. В связи с этим подчеркнем: макрокомандой является процедура, которая удовлетворяет следующим условиям:

Теперь закроем DocSub и создадим еще один документ с названием DocMain, включим в него модуль кода MainModule, в котором напишем макрокоманду

Попробуем ответить на вопрос: каким образом можно из макрокоманды DocMainMacro обратиться к процедурам DocSubProc1 и DocSubProc1 другого документа? Вопрос безусловно важный, так как при достаточно серьезной разработке часто требуется создать приложение в виде некоторой системы взаимосвязанных документов и их программных проектов.

Тривиальное решение проблемы — написать Call DocSubProc1 — не поможет, так как в этом случае мы получим сообщение о том, что такой процедуры нет.

Отложим на время решение поставленного вопроса и разберемся сначала с некоторыми базовыми вещами. В первую очередь отметим, что в общем случае обращение к процедуре имеет вид:

То есть для точной идентификации процедуры требуется (но не обязательно) дополнительно указывать имена проекта и модуля, где она содержится.

Важное замечание. Обратите внимание, что в данном случае используется параметр ProjectName — имя проекта, что совсем не одно и то же, что имя документа. Имя документа является обычным именем файла, причем в общем случае для однозначной его идентификации — с указанием полного пути к нему. Имя проекта — это специальный внутренний идентификатор, с помощью которого осуществляется взаимодействие программной части документов и шаблонов. По умолчанию при создании нового документа его проекту присваивается стандартное имя — Project. Так что два созданных нами документа имеют одинаковые имена проектов, что никак не влияет на работу, если документы используются в автономном режиме. Но в случае программного взаимодействия часто необходимо, чтобы имена проектов были разными. Имена устанавливаются в окне Properties для единственного свойства проекта Name. Учитывая это, изменим имена проектов для наших документов на ProjMain и ProjSub (мы используем разные идентификаторы для проекта и документа, чтобы различать эти понятия). Отметим также, что шаблон Normal.dot имеет фиксированное имя файла и проекта, поэтому в окне Project он обозначен одним идентификатором — Normal.

В каких случаях необходимо использовать расширенный вариант обращения к процедурам? Для ответа на этот вопрос рассмотрим небольшой пример. Включите в документ DocMain еще один новый модуль кода (Module1) и создайте в нем процедуру:

Теперь сделайте в DocMainMaсro обращение к этой процедуре Call TestProc и запустите макрокоманду — все сработает нормально. Включите в этот документ еще один модуль (Module2) с такой же процедурой (только поменяйте выдаваемое сообщение, чтобы различить работу процедур). Запустите на выполнение DocMainMacro, и вы получите сообщение об ошибке: двусмысленность имени процедуры. В этом случае для обращения к нужной подпрограмме нужно изменить формат обращения, указав имя модуля:

Разумеется, при работе внутри одного проекта его имя указывать не нужно. Обратите внимание, что при использовании дубликатных имен процедур в списке макрокоманд произойдут соответствующие изменения — они будут обозначаться полными именами.

Совет: Следите за появлением подсказок! После ввода имени модуля редактор выдает подсказку с перечнем доступных процедур. Отсутствие такой подсказки говорит о том, что вы ввели неверное имя модуля (или соответственно недоступного проекта). Попробуйте обратиться к процедуре другого проекта следующим образом:

Еще при вводе этого кода вы увидите, что проект ProjSub является недоступным (не появится подсказка). При запуске макрокоманды DocMainMacro появится сообщение о не найденном идентификаторе.

Еще один вариант контроля ввода доступных имен переменных и объектов выглядит так. Обычно принцип использования смысловых имен переменных подразумевает использование в идентификаторе строчных и прописных букв. Так вот, при вводе программного кода используйте только нижний регистр (строчные буквы) — тогда при завершении ввода оператора редактор VBA автоматически преобразует имя в вид, указанный в описании переменной или объекта.

Теперь попробуем поработать с процедурами шаблона Normal.

Внимание! Я не рекомендую без особой нужды вносить изменения в шаблон Normal. Для пользовательских настроек лучше создать отдельный шаблон, который может автоматически загружаться при запуске Word в качестве глобального, если его записать в каталог C:WindowsAppication DataMicrosoftWordStartUp или в каталог …Office2000StartUp.

При экспериментах с Normal.dot (чем мы сейчас и займемся) лучше сделать его исходную копию и при завершении исследований восстановить ее. Более того, иметь копию Normal всегда полезно...

Включите в Normal модуль Module1 с такой процедурой:

К ней можно обратиться из макрокоманды DocMainMacro с помощью любого из перечисленных ниже вариантов

Из этого можно сделать несколько промежуточных выводов:

Важное замечание. Само обращение к процедуре внешнего проекта можно сделать только потому, что ProjMain имеет ссылку на него в виде Normal: посмотрите раздел References в описании проекта в окне Project — она была установлена при создании документа, так как присоединенным шаблоном был указан Normal. Название же проекта можно опустить в обращении, так как имя NormalProc является уникальным для обоих проектов.

Создайте в Normal и в ProjSub две процедуры с одинаковыми именами CommonProc. Тогда для обращения к процедуре Normal из макрокоманды DocSubMacro нужно обязательно указать имя проекта:

А для обращения к процедуре своего же проекта достаточно записать только ее имя:

Еще один интересный момент. При записи Call Normal появится подсказка с перечнем допустимых элементов данного обращения. Здесь нужно обратить внимание на два момента:

Нам пока не очень понятно, как можно связать два документа Word, однако все мы знаем, что этот текстовый процессор предоставляет два варианта связи документов и шаблонов. Наверняка это может как-то помочь нам в организации их программного взаимодействия. Поэтому сейчас мы запишем на диск созданный ранее документ DocSub.doc, а также сохраним его же в формате шаблона с именем DocSub.dot и затем закроем этот шаблон. Теперь у нас в среде Word находится только один документ DocMain, и мы попробуем подключить к нему программные компоненты шаблона DocSub.dot.

С помощью диалогового окна Templates and Add-ins подключим DocSub.dot к документу DocMain.doc в виде глобального шаблона. Затем перейдем в среду VBA (напомним, что код глобальных шаблонов не доступен для просмотра и редактирования).

Все попытки обратиться из макрокоманды DocMainMacro напрямую к процедуре DocSubProc1 опять завершатся неудачей — код проекта глобального шаблона является недоступным для документа. Но то, что нельзя сделать путем прямого обращения к процедуре с помощью оператора Call, можно выполнить с использованием метода Run:

Application.Run “DocSub.SubModule.DocSubProc1”

Подробнее об использовании метода Run читайте в этой статье ниже, а пока закройте этот глобальный шаблон.

С помощью того же окна Templates and Add-ins подключите DocSub.dot в виде присоединенного шаблона. Теперь будет работать любой вариант обращения к DocSubProc1 из макрокоманды DocMainMacro:

При этом вы можете с удивлением обнаружить, что все процедуры шаблона Normal стали недоступными для нашего проекта ProjMain — ссылку на Normal заменила ссылка на DocSub.dot.

Однако все наши исследования по «доступности/недоступности» программных проектов были бы гораздо эффективнее, если бы мы сразу использовали команду View|Object Browser (F2).

Откройте документ DocMain.doc с присоединенным шаблоном DocSub.dot, выделите в среде VBA в качестве активного проекта ProjMain и нажмите F2. Раскройте в окне Object Browser список Project/Library — здесь приведен перечень всех проектов и библиотек, доступных в данный момент активному проекту ProjMain. Ниже в окне Classes приведен список компонентов выделенного проекта, а в окне Members — процедур.

Здесь нужно иметь в виду, что, хотя, например, для проекта ProjSub будут показаны включенные в него модули форм и классов (если бы мы их вставили), они будут недоступны для программного обращения для ProjMain.

Обратим внимание еще на один любопытный момент. Для его иллюстрации прямо в среде VBA измените для шаблона DocSub.dot имя проекта с ProjSub на ProjMain (то есть установите для двух проектов одинаковые имена), опять откройте окно Object Browser и сравните это изображение с рис. 7. Видно, что в списке вместо двух проектов ProjSub и ProjMain остался только последний, причем он относится к шаблону DocSub.dot (см. состав модулей в окне Classes). А документ DocMain.doc вообще не представлен в Object Browser. Однако если вы начнете вводить в макрокоманде DocMainMacro код Call ProjMain, то по появившейся подсказке легко догадаетесь, что в данном случае под ProjMain подразумевается как раз документ DocMain.

Из этого можно сделать два вывода. Первый — при подключении одноименного проекта будут доступны его процедуры только с уникальными именами (для одноименных процедур нужно обязательно указать название проекта). Второй — лучше, чтобы все проекты имели свои уникальные имена — у вас будет больше возможностей и меньше головной боли.

За разговорами «вокруг да около» мы вплотную подошли к проблеме, обозначенной в первом пункте статьи, — как связать два документа Word. Просмотрев состав доступных программных компонентов в окне Object Browser, вспомним, что для их подключения в среде VB используется команда References (меню Tools).

Давайте откроем это окно — в нем мы увидим ссылки именно на те проекты и библиотеки, что и в Object Browser. Отсюда становится очевидным универсальный механизм подключения проектов (как шаблонов, так и документов!) к документу: это можно сделать путем установки ссылок на нужные вам документы и шаблоны в окне References. (Чтобы не путать наш исходный документ DocSub.doc с шаблоном DocSub.dot, изменим имя проекта шаблона на DocSubTemplate.) Теперь отметим несколько особенностей подключения проектов с помощью References в среде VBA:

Итак, задача организации программной связи двух документов Word решена. Но тут появляется другая заманчивая идея — а нельзя ли устанавливать эти связи программным способом, чтобы, например, уже в ходе выполнения программы определять, какие проекты нужны, и динамически устанавливать необходимые ссылки? Эта задача решается легко!

Чтобы разобраться с этим вопросом, отключите все ссылки проекта ProjMain (документ DocMain), перезагрузите Word и откройте DocMain с присоединенным Normal (то есть все по минимуму). Перейдите в среду VBA.

Посмотреть программным способом полный список ссылок для активного проекта, который представлен в окне Tools|References, можно с помощью такого кода:

Разумеется, свойств у проекта гораздо больше и многие из них будут полезны для использования в практической работе, но нам пока хватит этих двух.

Хочу обратить внимание на то, что здесь мы применили программную конструкцию, которая решает некоторые практические проблемы разработчика (подробнее об этом см. статью «Особенности технологий раннего и позднего связывания в Visual Basic»).

После выполнения этого кода вы получите такой результат в окне Immediate:

Для управления связью проектов нам также пригодится механизм доступа к списку загруженных в данный момент в среду Word документов и шаблонов

Результат выполнения кода:

Обратим внимание на большую схожесть приведенных выше двух фрагментов кода. Но заметна также несогласованность в именах одинаковых свойств: в одном случае полное имя файла определяется свойством FullPath, в другом — FileName.

Здесь следует еще раз подчеркнуть, что каждый документ или шаблон характеризуется двумя важными идентификаторами — полным именем файла и именем проекта. Из приведенных выше фрагментов понятно, что по имени загруженного документа можно всегда программным образом узнать имя проекта. А по списку в окне References (здесь находятся проекты с уникальными именами) можно выполнить обратную операцию. Далее мы будем считать, что изначально нам известно только имя файла (с указанием полного пути!), для которого мы отведем переменную FileName$. Вычисляемое имя проекта будет храниться в ProjectName$.

Нам также понадобится функция, которая будет определять, находится ли указанный файл в списке ссылок активного документа:

Конечно, можно было бы задать в качестве искомого параметра имя проекта, и тогда код процедуры будет выглядеть гораздо проще:

Но все же мы остановимся на первом варианте, так как если мы хотим загрузить новый файл, то имя его проекта нам пока просто не известно (мы его узнаем в момент подключения).

Внимание при использовании объекта ActiveDocument! Здесь нужно ответить на важный вопрос — что мы понимаем (точнее, что понимает Word) под активным документом? При работе в среде VBA может сложиться впечатление, что активным документом является тот, с проектом которого мы работаем в данный момент. Но это не так!

Активный документ Word — тот, с которым мы работали в среде самого редактора перед переходом в VBA. Чтобы разобраться в этом вопросе, проведите такое исследование. Загрузите Word и откройте два документа — DocMain.doc и DocSub.doc. В данном случае проследите, чтобы первый документ не содержал ссылок на DocSub.doc.

Перейдите в среду VBA и создайте для первого документа такую макрокоманду:

Перед ее запуском попробуйте ответить на вопрос — какой документ и какой проект является активным в данный момент? Ответ относительно проекта легко получить, взглянув на окно Project, — наверняка там выделен сейчас DocMain (мы создавали процедуру для него). При работе с Word 97 определить, какой документ является активным, можно — его имя будет видно на кнопке панели задач. Но в Word 2000 это сделать не удастся, так как здесь каждый открытый документ имеет собственную кнопку, а активной кнопкой сейчас является VBA.

Так вот, если вы выполняли действия в приведенной выше последовательности, то активным документом будет DocSub.doc, так как он загружался последним. Тем не менее на всякий случай активизируйте DocSub.doc в среде Word, перейдите в VBA, активизируйте проект ProjMain, запустите на выполнение макрокоманду TestMacro и убедитесь, что имена файлов для активного шаблона и активного документа не совпадают.

Если вы теперь подключите DocSub.doc к DocMain.doc с помощью окна References и попробуете запустить макрокоманду DocMainMacroMyRef, то увидите, что вы получили список ссылок DocSub, а не DocMain, как хотелось бы.

Обратим внимание, что путаница при запуске макрокоманды возможна только при работе в среде VBA. При обращении из среды Word с помощью команды Tools|Macro|Macros доступны макросы только активного документа, проект которого также автоматически становится активным.

Однако на этом сюрпризы не кончаются. Если вы закроете DocMain и DocSub, а потом опять откроете DocMain (к которому подключен DocSub), перейдете в среду VBA и в ней запустите TestMacro, то опять обнаружите несовпадение активного документа и активного проекта. Дело в том, что в момент запуска макрокоманды произойдет автоматическая загрузка присоединенного документа DocSub.doc, который и станет активным.

Аналогичные фокусы могут происходить при программном подключении DocSub к DocMain. При первом обращении

все сработает нормально — будет произведено подключение файла к DocMain. Однако при повторном обращении появится сообщение об ошибке. Причина этого заключается в том, что при подключении файла SubDoc выполнится его загрузка и он станет активным документом. При втором обращении поиск ссылок будет выполняться для DocSub и потом последует попытка подключить этот файл к самому себе.

Решение этой проблемы выглядит, казалось бы, тривиально — нужно во всех приведенных выше программах заменить ActiveDocument на VBE.ActiveVBProject, то есть забыть об активном документе и иметь дело только с активным проектом. Но проблема заключается в том, что при установке новой ссылки меняется и активный проект.

Выход тут один — следить за тем, чтобы активный документ и активный проект соответствовали одному и тому же файлу.

Если же вы работаете в среде VBA, то в стартовой макрокоманде можно установить такую принудительную активизацию документа:

А для контроля за возможным изменением статуса активного документа при установке ссылок можно модернизировать код процедуры CreateReference следующим образом:

Отметим, что установка активного документа автоматически делает активным его проект. Все работает.

Теперь мы подошли вплотную к волнующему моменту — собственно к программному подключению документа DocSub.doc к документу DocMain и обращению к процедуре первого DocSubProc1. Это может выглядеть следующим образом:

Казалось бы, задача решена, но тут мы столкнемся еще с одним препятствием. Такая конструкция будет работать, только если установка ссылки на DocSub уже была выполнена перед запуском макрокоманды (точнее, проекта DocMain). А при динамическом подключении файла будет выдана ошибка: не определена процедура DocSubProc1. Здесь можно применить хитрость, заменив прямое обращение к этой процедуре вызовом промежуточной подпрограммы:

Однако такой вариант будет работать только при установке режима Compile On Demand (вкладка General окна Tools|Options), что я как раз не очень советую делать, особенно при отладке программы (подробнее см. статью «Особенности технологий раннего и позднего связывания в Visual Basic» в этом номере).

Проблема обращения к процедурам динамически вызываемых проектов может быть решена с помощью метода Run. Лично мне в свое время показалось весьма странным само наличие этого метода, так как обращения к макрокоманде

и

совершенно идентичны по смыслу. Но на самом деле между ними наблюдаются довольно существенные различия, когда речь идет о совместной работе проектов, и в этом нужно разобраться. Специфика метода Run (об этом не говорится в документации, эти выводы сделаны в ходе экспериментов и нуждаются в более тщательном изучении) заключается в следующем:

С учетом этого обращение к процедуре загруженного (!) документа выглядит следующим образом:

Теперь о различиях Word 97 и 2000. В Word 97 можно было обращаться только к макрокомандам, в Word 2000 — к любым глобальным процедурам модулей кода, то есть передавать параметры в подпрограммы и функции. Так что в Word 2000 можно обратиться к процедуре DocSubProc2, которую мы написали в самом начале этой статьи. Но обращение это выглядит довольно странно:

То есть даже к подпрограмме нужно обращаться как к функции (это вполне допустимо и в обычных случаях, просто не очень понятно, что именно возвращается в качестве результата). Кроме того, у меня совершенно не получилось использовать имя проекта в качестве уточнения координат функции (то есть нельзя обращаться к функциям с дубликатными именами).

Достоинства метода Run представляются довольно очевидными — можно производить динамическую настройку вашего проекта для вызова любых проектов и их процедур в процессе работы программы, не опасаясь проблем с компиляцией кода и неопределенностью внешних ссылок. Например, пользователь может ввести с клавиатуры имя документа, модуля и процедуры:

Если для VBA можно использовать два способа обращения к процедурам внешних проектов, то для VB-проектов вариант только один — использование метода Run. Вот как это может выглядеть при обращении к процедуре DocSubProc1 документа DocSub.doc в Visual Basic:

К сожалению, должен отметить, что обращение к подпрограмме DocSubProc2 с передачей параметров у меня не получилось.

Кстати, в среде VB также можно осуществлять динамическое подключение ActiveX DLL, то есть программным способом делать ссылки, обычно выполняемые в окне Project|References. Для этого нужно сначала вручную сделать ссылку на Microsoft Word 9.0 Object Library, чтобы получить доступ к объекту VBE (не очень понятно, почему такой глобальный объект находится в библиотеке отдельного приложения, а не в Office Object Library), и выполнить, например, такой код:

Из всего сказанного выше можно сделать такой вывод: для обращения к программному коду внешнего документа или шаблона Word существует два метода:

Листинг. Процедуры CreateReference и Delete Reference Function CreateReference&(FileName$, ProjectName$)    ' Создание ссылки на указанный файл    ' ВХОД: FileName$ - имя файла    ' ВЫХОД:    ' CreateReference& = 0 - файл подключен    ' = -1 - был подключен ранее    ' ProjectName$ - имя проекта    ' = другое - код ошибки    ' (ProjectName$ = ""    Dim Ref As Object ' On Error GoTo CreateReferenceError    Set Ref = TestReference(FileName$)    If Ref Is Nothing Then ' подключаем файл      Set Ref = ActiveDocument.VBProject.References.AddFromFile(FileName)      CreateReference = 0    Else ' уже подключен      CreateReference = -1    End If    ' определяем имя проекта    ProjectName$ = Ref.Name ' позднее связывание!!! Exit Function CreateReferenceError: ' ошибка при подключении 'например, нелегальный тип файла или дубликатное имя проекта CreateReference = Err ProjectName$ = "" End Function Function DeleteReference(FileName$) As Boolean ' Удаление ссылки на указанный файл ' ВХОД: FileName$ - имя файла ' ВЫХОД: DeleteReference = True - ссылка была ' = False - ссылки не было Dim Ref As Object Set Ref = TestReference(FileName$) If Not (Ref Is Nothing) Then ' отключаем ссылку ActiveDocument.VBProject.References.Remove Ref End If DeleteReference = Not (Ref Is Nothing) End Function