| ||||||||||||||||
 | ||||||||||||||||
| ||||||||||||||||
 | ||||||||||||||||
| ||||||||||||||||
|
|
Документы Office 2000 и их проекты. Объектная модель и программная работа с программными проектами Всюду, где только можно, я не уставал повторять, как заклинание, что для офисного программиста целью работы является создание документа, частью которого является программный проект, неразрывно связанный с документом. Более того, в серьезных разработках речь всегда идет о создании системы документов, а, следовательно, и о системе программных проектов, связанных с этими документами, так и с помощью ссылок непосредственно друг с другом. Программные проекты в такой системе могут иметь общий пул памяти, общие процедуры, вызываемые из любого проекта. О проектировании такой системы документов, о связывании программных проектов ссылками я подробно рассказывал в своей книге [2. В.А. Биллиг "VBA в Office 2000. Офисное программирование", гл.2 ]Теперь же я хочу рассмотреть отношения между документами и проектами с объектной точки зрения, рассмотреть основной объект VBProject, задающий проект, его компоненты, его связь с объектом Document и коллекцией VBProjects, хочу рассмотреть вопросы программной работы с этими объектами. Всюду в этом тексте я буду говорить о документах Word и их программных проектах. Но нужно понимать, что объектная модель проектов практически одна и та же для всех документов Office 2000. Замечу также, что многое из того что я буду рассказывать относится и к предыдущей версии Office 97. В отличие от других документов Office документы Word обладают той особенностью, что с каждым из них связаны два проекта. Один - Normal - стандартный проект, общий для всех документов, а второй - отражает специфику документа. Этот второй проект обычно и называют проектом данного документа и именно о нем пойдет основной наш разговор. Но прежде несколько слов о проекте Normal. Все документы Word открываются по умолчанию на основе шаблона Normal, частью этого шаблона и является, связанный с шаблоном проект Normal. Все макросы, хранимые в проекте Normal являются доступными для любого из документов Word. Именно сюда помещает программист все макросы, стандартные модули или модули классов, которые по его мнению будут использоваться всеми документами Word на данном компьютере. Нужно однако понимать, что при размещении макроса в проекте Normal, речь должна идти действительно только об общезначимых программных инструментах. В остальных случаях все программные компоненты должны быть связаны с проектом конкретного документа. Замечу кстати, что иногда помещение программных компонент, чаще всего макросов, в проект Normal происходит по недоразумению, поскольку по умолчанию местом размещения создаваемых MacroRecorder макросов является именно проект Normal, а не проект данного документа. Так что будьте внимательны в таких ситуациях. Но давайте перейдем к рассмотрению объектной модели проекта документа Word. Объект Document имеет свойство VBProject, возвращающее объект, задающий программный проект данного документа. Прежде, чем поговорить об этом объекте, давайте подымемся на несколько этажей выше. Я напомню, что корневым объектом, содержащим все объекты VBA, является объект VBE (Visual Basic Environment). У этого объекта есть только свойства, позволяющие получить доступ к объектам VBA, лежащих на нижних уровнях иерархии. В частности, такие свойства объекта VBE, как ActiveWindow, ActiveVBProject, SelectedVBComponent позволяют получить доступ к активному окну, активному программному проекту или выбранной компоненте проекта. Свойства AddIns, CommandBars, Windows позволяют получить доступ к коллекциям элементов AddIn, панелей, и окон. Есть, конечно, у объекта VBE и свойство VBProjects, возвращающее коллекцию всех открытых программных проектов. Заметьте, если одновременно открыто N документов Word, то коллекция VBProjects будет содержать не менее чем N+1 элемент, ѕ по одному проекту на документ плюс общий для всех проект Normal. Видите, я говорю осторожно ѕ "не менее". В среде Office 97 их было бы ровно N+1, в Office 2000 их может быть больше. В Office 2000 возможности работы с программными проектами документов существенно расширились. У объекта VBProject и коллекции VBProjects в Office 2000 появилось большое число новых свойств и методов. Замечу, что определенную сложность в изучение этого материала вносит то обстоятельство, что в справочной системе справки по многим объектам, связанным с проектами, отсутствуют или, что еще хуже, содержат неполные сведения, не отражающие действительной картины. Так было и в Office 97, такая же ситуация имеет место и в Office 2000. Скажем несколько слов о коллекции VBProjects. В Office 97 у этой коллекции имелись три простых свойства ѕ Count, Parent, VBE и единственный метод - Item. У нее не было методов Add и Delete, так как проекты были прочно связаны со своими документами и удалялись и появлялись одновременно со своими документами. В Office 2000 у этой коллеции появились три метода для добавления проектов в коллекцию ѕ Add, AddFromFile, AddFromTemplate, соответственно появился и метод Remove для удаления элементов коллекции. Помимо этого, коллекция имеет методы SaveAs и FileName для сохранения проектов, появились также и новые свойства, в частности свойство StartProject. С этими новыми свойствами и методами еще предстоит разобраться. В "обычной" Premium версии Office 2000 они не работатют. По-видимому, их можно использовать в версии Developer. Я пока не провел необходимых исследований и посему не готов дать точный ответ даже на такой простой вопрос, что значит добавить проект в коллекцию VBProjects, значит ли это, что он будет связан со всеми открытыми документами? Имея коллекцию VBProjects, добраться до отдельного проекта нетрудно, делается это обычным для коллекций способом, Можно, конечно, использовать метод Item, но, проще всего, указать индекс элемента в коллекции, при этом роль индекса может играть и имя проекта. Так что спуститься по иерархии сверху вниз нетрудно: VBE.VBProjects(1) дает ссылку на первый проект коллекции. Также просто и от отдельного проекта перейти вверх по иерархии. Объект VBProject имеет свойство Collection, позволяющее получить коллекцию VBProjects, а его свойство VBE позволяет подняться еще выше по иерархии и добраться до корневого объекта VBE; от корня можно уже спуститься в любую заданную точку. Итак, разобрав, как связан объект VBProject с объектами, вышестоящими в иерархии, давайте более подробно остановимся на его свойствах и методах. В Office 97 объект класса VBProject имел только свойства и не имел методов. О двух свойствах этого объекта ѕ Collection и VBE я уже упомянул, они позволяют подняться по иерархии. Свойства Description и Protection позволяют получить описание проекта и определить, защищен ли он. Свойства HelpFile и HelpContextId позволяют указать справочную систему по проекту, если таковая существует. Наиболее важными, пожалуй, свойствами являются свойства VBComponents и References. Свойство VBComponents возвращает коллекцию компонент проекта: модули, классы и формы, входящие в проект. Имея эту коллекцию, можно перейти к соответствующей компоненте и программно работать с ней. Свойство References позволяет получить доступ к коллекции ссылок на элементы, доступные из данного проекта. Элементы этой коллекции соответствуют ссылкам, отображаемым в пункте References меню Tools в среде редактора VB. В Office 2000 объект VBProject получил несколько новых свойств, например, свойства: CompatibleOleServer, IsDirty, Type. Первое из них возвращает или устанавливает строку, содержащую совместимый сервер Автоматизации для проекта. Булево свойство IsDirty, как обычно для свойства с таким именем указывает на внесение изменений в проект с момента последнего его сохранения. Свойство Type задает тип проекта, указывающим на то, что проект может относиться, например, к ActiveXDLL или ActiveXControl. Объект VBProject теперь имеет и методы. Метод MakeCompiledFile записывает проект в виде DLL, имя которой задается новым свойством BuildFileName. Метод SaveAs позволяет сохранить проект в указанном месте. Изменения в составе свойств и методов объектов VBProject и VBProjects симптоматичны. Они отражают тенденцию к возрастению потребностей офисных программистов при работе с программными проектами документов. По моему ощущению, Office все шире применяется для создания достаточно серьезных приложений, включающих систему документов и связанную с ней систему программных проектов Перейдем теперь к рассмотрению примеров работы с объектом VBProject. Начнем с анализа терминальных свойств проектов: Public Sub WorkWithProjects()
'Анализ терминальных свойств проектов коллекции VBProjects
'Dim MyProject As VBProject
Dim MyProject As Object
Debug.Print "Число проектов в коллекции - ", VBE.VBProjects.Count
For Each MyProject In VBE.VBProjects
With MyProject
Debug.Print "Имя Файла - ", .FileName
Debug.Print "Имя проекта", .Name
Debug.Print "Тип проекта", .Type
Debug.Print "Описание проекта", .Description
Debug.Print "Статус защиты", .Protection
Debug.Print "Статус проекта", .Mode
'Debug.Print "Изменения Вносились? ", .IsDirty
Debug.Print "Имя Dll", .BuildFileName
'Debug.Print "Начальный статус", .StartMode
End With
Next MyProject
End Sub
Сама программа достаточно понятна. Я просто в отладочном режиме печатаю число открытых проектов и в цикле по коллекции VBProjects для каждого из проектов печатаю значения его основных терминальных свойств. Обратите внимание на два обстоятельства. В первых двух строчках программы дважды описана переменная MyProject ѕодин раз как VBProject, другой - как Object. Это не случайно. Когда я пишу текст программы, я пользуюсь первым из этих объявлений, задавая раннее связывание. Тогда я получаю нужные мне подсказки о свойствах и методах этого объекта и вложенных в него объектов. Без этих подсказок жизнь программиста становится невыносимой. Когда же я перехожу на выполнение программы, то приходится пользоваться вторым вариантом объявления, поскольку из-за недоработки в Office 2000 нормальная работа с этим объектом в документах Word возможна только при таком виде объявления, хотя в Excel работают и явные объявления типа VBProject. Заметьте также, что обращение к некоторым свойствам закомментированы. Это связано с тем, что не все заявленные новые свойства и методы реально работают в Premium версии Office 2000. Следует отметить еще один небольшой, но досадный "жучок", проявляющийся в этом месте. При появлении подсказки ряд существующих свойств и методов не показывается, хотя они фактически работают, например, не показывается свойство Protection и Mode. Списки свойств и методов объекта VBProject, но и не только этого объекта, просматриваемые в трех разных местах ѕ в справочной системе, в окне просмотра (браузере объектов) и при появлении подсказки в момент программирования, к сожалению, могут не совпадать. Есть смысл привести результаты тестовой печати при работе этой процедуры. Я выполнял ее в тот момент, когда были открыты два документа Word, один из них текст этой главы, второй ѕ тестовый документ, содержащий тексты выполняемых процедур. Вот результаты печати: Число проектов в коллекции - 3 Имя Файла - E:\O2000\Book2\CD\Ch1\DocOne.doc Имя проекта DocOneProject Тип проекта 100 Описание проекта Этот проект содержит примеры главы 2 Статус защиты 0 Статус проекта 0 Имя Dll E:\O2000\Book2\CD\Ch1\DocOne.DLL Имя Файла - E:\o2000\vBA2000\Normal Имя проекта Normal Тип проекта 100 Описание проекта Статус защиты 0 Статус проекта 0 Имя Dll E:\o2000\vBA2000\Normal.DLL Имя Файла - E:\O2000\Book2\Ch1\Ch1.DOC Имя проекта Project Тип проекта 100 Описание проекта Статус защиты 0 Статус проекта 0 Имя Dll E:\O2000\Book2\Ch1\Ch1.DLL Как и положено, при двух открытых документах коллекция VBProjects содержит три проекта. Проекту моего тестового документа я дал имя (DocOneProject) и указал для него описание. В следующем примере займемся анализом компонент и ссылок проекта. При этом я не ограничусь печатью свойств компонент и ссылок, но добавлю в проект новую компоненту, создав программно новую форму: Public Sub WorkWithVBProject()
'Компоненты и ссылки проекта
'Dim MyProject As VBProject
Dim MyProject As Object
'Dim MyComp As VBComponent
Dim MyComp As Object
'Dim MyRef As Reference
Dim MyRef As Object
Set MyProject = ActiveDocument.VBProject
With MyProject
'Печать имени и типа для каждой существующей компоненты проекта
Debug.Print "Число компонент проекта - ", .VBComponents.Count
For Each MyComp In .VBComponents
Debug.Print "Имя компоненты - ", _
MyComp.Name, "Тип - ", MyComp.Type
If MyComp.Name = "NewMacros" Then MyComp.Name = "DocOneMacros"
Next MyComp
'Добавление формы - новой компоненты проекта
.VBComponents.Add vbext_ct_MSForm
'Печать имени и типа для каждой существующей компоненты проекта
Debug.Print "Число компонент проекта - ", .VBComponents.Count
For Each MyComp In .VBComponents
Debug.Print "Имя компоненты - ", _
MyComp.Name, "Тип - ", MyComp.Type
If MyComp.Name = "NewMacros" Then MyComp.Name = "DocOneMacros"
Next MyComp
'Печать имени и типа для каждой существующей ссылки проекта
For Each MyRef In .References
Debug.Print "Имя ссылки -", _
MyRef.Name, "Тип -", MyRef.Type
Next MyRef
End With
End Sub
Приведу результаты отладочной печати по завершении работы этой процедуры: Число компонент проекта - 4 Имя компоненты - ThisDocument Тип - 100 Имя компоненты - Examples Тип - 1 Имя компоненты - DocOneMacros Тип - 1 Имя компоненты - Examples1 Тип - 1 Число компонент проекта - 5 Имя компоненты - ThisDocument Тип - 100 Имя компоненты - Examples Тип - 1 Имя компоненты - DocOneMacros Тип - 1 Имя компоненты - Examples1 Тип - 1 Имя компоненты - UserForm1 Тип - 3 Имя ссылки - VBA Тип - 0 Имя ссылки - Word Тип - 0 Имя ссылки - stdole Тип - 0 Имя ссылки - Normal Тип - 1 Имя ссылки - Office Тип - 0 Имя ссылки - MSForms Тип - 0 Имя ссылки - VBIDE Тип - 0 Конечно, главным итогом работы процедуры является не столько отладочная печать, сколько появление новой формы, которую можно заполнять программно или вручную. Приведенные примеры программной работа с проектом достаточно просты. Два более сложных примера на эту тему можно найти в моей уже упоминавшейся книге [2. стр. 442- стр. 446], где я отвечал на два вопроса одного из читателей:
При ответе на первый вопрос я, во-первых, показал, как программно добавляются в созданную форму элементы управления, во-вторых, как использовать свойство Designer для придания форме, с которой работает программист, статуса режима проектирования. Сейчас я хочу рассмотреть одну важную тему при работе с программными проектами. Иногда работа программиста с проектом заключается в том, что он программно должен изменить сам текст проекта, добавляя новые модули, новые процедуры и обработчики событий, корректируя текст модуля и его отдельных процедур, создавая или меняя свой проект, как говорят, "на лету". Я уже говорил о том, что, благодаря коллекции VBComponents, можно добраться до каждого модуля проекта, а благодаря свойству CodeModule, получить код модуля. Свойством CodeModule обладает объект VBComponents("NameofModule"), задающий модуль проекта с именем NameOfModule. При вызове этого свойства возвращаеся объект CodeModule, определящий код модуля. У этого объекта много важных и полезных свойств и методов, необходимых при программной работе с кодом проекта. Благодаря таким свойствам как CountOfLines, CountOfDeclarationsLines, ProcCountLines, можно узнать число строк в модуле, число строк в разделе объявлений, число строк в процедуре модуля с заданным при вызове именем. Работая со свойством Members, можно получить полную информацию обо всех элементах модуля. Свойства ProcBodyLine и ProcStartLine возвращают номер строки, с которой начинается процедура или предшествующей ей строки. Свойство Lines возвращает заданное число строк процедуры, свойство ProcOfLine возвращает имя процедуры, содержащей заданную при вызове строку. Если свойства объекта CodeModule позволяют проанализировать состав модуля и добраться до каждой из его процедур, то методы объекта позволяют вставлять, заменять и удалять строки кода, так что можно "на лету" провести коррекцию процедуры, удалить или добавить новую процедуру и/или объявление переменной. Методы AddFromFile и AddFromString позволяют добавить в модуль текст, сохраненный в либо в файле, либо непосредственно в строке. Первый метод, как правило, используется для введения больших изменений в модуле, второй при небольших корректировках. Заметим, что если нужно полностью добавить новый модуль, то удобнее пользоваться методом AddFile или AddFromTemplate коллекции VBComponents. Методы InsertLines, DeleteLines и ReplaceLines позволяют вставить, удалить или заменить строки программного текста в указанной точке. Функция CreateEventProc позволяет создавать процедуры указанных событий. Функция Find позволяет осуществлять полномасштабный поиск в модуле. В каких ситуациях возникает необходимость в программном создании или корректировке кода проекта? На первый взгляд тексты программ всегда можно создавать "вручную". Однако так кажется только "на певый взгляд". На практике такая потребность возникает достаточно часто. Сейчас я рассмотрю одну из таких ситуаций, в которой имеет смысл программное создание кода проекта. В этом примере я использую большинство из вышеупомянутых свойств и методов объекта CodeModule. Содержательно, задача, решаемая в примере, состоит в следующем: Необходимо создать шаблон документа, такой, чтобы все документы, открывающиеся на основе шаблона, содержали обработчик события Open, одинаково реагируя на каждое открытие документа. Замечу, что хотя сам шаблон может содержать обработчик этого события, но документы, открываемые на его основе, обладать этим обработчиком не будут. Однако добавить этот обработчик в документ можно программным путем, в тот момент, когда создается документ на основе шаблона. Понятно, что для этого необходимо задать соответствующий код в обработчике события New нашего шаблона. Чтобы чуть усложнить задачу и сделать ее более конкретной, будем также полагать, что документы, создаваемые на основе шаблона должны иметь переменную - счетчик, следящую за числом открытия документа. Такие счетчики полезны, когда пользователю предоставляется демо-версия, рассчитанная на фиксированное число открытий документа. Таким образом, шаблон должен гарантировать также появление переменной, назовем ее Counter, в коллекции Variables каждого нового документа, создаваемого на основе шаблона. Итак наша цель состоит в том, чтобы создать шаблон документа. В обработчике события New для этого шаблона, вызываемого в тот момент, когда на основе шаблона создается новый документ, предусмотреть решение следующих задач:
Понятно, что, помимо всего прочего, этот пример демонстрирует программное создание кода проекта документа. Для решения этой задачи нам придется широко использовать свойства и методы объекта CodeModule, так что настал его черед. Вот код обработчика события New, встроенный в шаблон документа с именем DocWithCounter: Private Sub Document_New()
Const MyPath = "e:\O2000\Book2\Cd\Ch1\"
Const Lin1 = "OpenDoc"
Dim Beg As Long
'Создание переменной - хранителя информации в новом документе
With ActiveDocument.Variables
If Not ExistVar("CounterDoc") Then
'Добавляем переменную
.Add Name:="CounterDoc", Value:=0
End If
End With
With ActiveDocument.VBProject.VBComponents("ThisDocument").CodeModule
'Создание процедуры - события в новом документе
Call .CreateEventProc("Open", "Document")
'Определение точки вставки в процедуру
'Beg = .ProcStartLine("Document_Open", 0)
Beg = .ProcBodyLine("Document_Open", 0)
'Вставка текста в процедуру
Call .InsertLines(Beg + 1, Lin1)
End With
'Добавление модуля в проект нового документа
ActiveDocument.VBProject.VBComponents.Add (vbext_ct_StdModule)
'Переименование модуля
ActiveDocument.VBProject.VBComponents("Module1").Name = "AddedModule"
With ActiveDocument.VBProject.VBComponents("AddedModule").CodeModule
'вставка текста процедуры из файла
.AddFromFile (MyPath & "AddingModule.bas")
End With
End Sub
Процедура довольно хорошо прокомментирована, тем не менее я позволю обратить Ваше внимание на следующие моменты:
Как видите, в этом примере документы получают программный проект при рождении. В этом проекте есть стандартный модуль, обработчик событий и все это создается "на лету" программным путем. Теперь я хочу рассмотреть еще один пример, являющийся ответом на следующий вопрос одного из моих читателей:
Задача Сергея Шершнева (так зовут моего читателя) состояла в том, что, работая с системой документов, ему в зависимости от выбора пользователя необходимо было подключать программные проекты тех или иных документов. Чтобы получить доступ в главном документе к процедурам подключенных проектов, ему необходимо было предварительно программно установить ссылки на подключаемые проекты. Не буду вдаваться во все тонкости его проблем и рассмотрю лишь две конкретные задачи, ѕ как программно включить (выключить) ссылку на программный проект и как вызывать процедуры подключенных проектов. Для ответа на эти вопросы рассмотрим следующую ситуацию. Пусть у нас есть главный документ DocOne и два других документа DocTwo и DocThree. Все три документа обладают программными проектами. Открыв главный документ, мы интересуемся предпочтениями пользователя и, в зависимости от его выбора подключаем документ DocTwo или DocThree, вызывая затем соответствующие процедуры подключенного документа. По ходу дела необходимо также уметь отключить ранее подключенный документ. Рассмотрим одно из возможных решений этой задачи. Прежде, чем перейти к непосредственному решению задачи, сделаю одно замечание. Решение задачи начинается с выяснения предпочтений пользователя. Типичное решение задачи о выборе предпочтений пользователя состоит в том, что ему предъявляется форма, содержащая список всех допустимых возможностей. В этом списке пользователь и задает свой множественный выбор. О работе со списками в формах я рассказывал достаточно подробно, например в [1. В.А. Биллиг, М.И. Дехтярь "VBA и Office 97. Офисное программирование", стр. 520 - 533 ], [2. стр. 60 - 65]. Сейчас я ограничусь более простой процедурой, учитывающей мой частный случай работы с документами: Public Sub ChooseProject(NoF As String, NoP As String) Const Msg = "Введите имя файла, " & _"хранящего документ и его программный проект!" NoF = InputBox(Msg, "Projects", "DocTwo.doc") Const Msg1 = "Введите имя проекта, хранящегося в документе!" NoP = InputBox(Msg1, "Projects", "DocTwo") End Sub Заметьте, для работы со ссылками, -- их программного подключения и отключения необходимо знать имя файла, в котором хранится сам подключаемый документ и имя проекта этого документа. В моем примере я проектам во всех документах давал имя, совпадающее с именем документа. Это нашло отражение в установках, задаваемых по умолчанию в функции InputBox. Вызов функции ChooseProject позволяет установить предпочтения пользователя. Зная их, можно включить соответствующую ссылку на документ. Вот как это делается: Public Sub CreateRef()
'Создание ссылки на проект с именем NoP
' хранящийся в файле с именем NoF
Dim MyPath As String
Dim MyRef As Object
Dim NameOfProject As String
Dim NameOfFile As String
'Выбор добавляемого проекта
Call ChooseProject(NameOfFile, NameOfProject)
'Запоминание глобальных переменных программы
NoF = NameOfFile
NoP = NameOfProject
With ActiveDocument
MyPath = .Path
'Вставка ссылки
If Not ExistRef(NameOfProject, MyRef) Then
.VBProject.References.AddFromFile MyPath & _
"\" & NameOfFile
End If
CallProcFromProject
Debug.Print "Имя файла -", NoF, "Имя проекта -", NoP
End With
End Sub
Как видите, для подключения ссылки я использую метод AddFromFile коллекции References. В качестве параметра необходимо задать полный путь к файлу, содержащему документ с подключаемым проектом. Имя проекта при этом указывать не нужно, -- оно автоматически будет найдено в документе. Обратите внимание на использование переменной MyPath, задающей путь к активному документу. Я предполагаю, что активным является мой главный документ. Второе, более сильное предположение состоит в том, что все подключаемые документы находятся в одном каталоге с главным. Это позволяет безболезненно переносить все документы на другой компьютер и размещать их в любом каталоге. Заметьте также, что прежде, чем добавить ссылку, я проверяю возможность существования ее в коллекции ссылок, чтобы исключить ее повторную запись. Булева процедура ExistRef решает эту задачу. Первый параметр NameOfProject является входным и задает имя проекта, ссылку на который мы ищем. Второй параметр - MyRef является выходным и задает объект класса Reference, найденную ссылку в случае успеха поиска. Вот текст этой функции: Public Function ExistRef(Name As String, Refery As Object) As Boolean
'Определяет наличие ссылки с
'именем Name в коллекции References
'Возвращает ссылку при ее обнаружении
Dim MyRef As Object
Set Refery = Nothing
ExistRef = False
For Each MyRef In ActiveDocument.VBProject.References
If MyRef.Name = Name Then
Set Refery = MyRef
ExistRef = True
Exit For
End If
Next MyRef
End Function
Программно удалить ссылку также просто, как и ее добавить. Вот текст соответствующей процедуры: Public Sub RemoveRef() 'Удаление ссылки на проект с именем NoP Dim MyRef As Object Dim NameOfProject As String Dim NameOfFile As String 'Выбор удаляемого проекта Call ChooseProject(NameOfFile, NameOfProject) 'Удаление ссылки If ExistRef(NameOfProject, MyRef) Then ActiveDocument.VBProject.References.Remove MyRef End If End Sub Для удаления ссылки я использую метод Remove коллекции References. В качестве параметра этому методу необходимо передать объект, задающий удаляемую ссылку. К счастью у нас уже написана функция ExistRef, которая по имени удаляемого проекта вернет ссылку на него. Поэтому все проблемы с удалением ссылки тем самым решены. Теперь, когда мы умеем включать и выключать ссылки на программный проект осталось рассмотреть, как обращаться к элементам этого проекта, ѕ его общедоступным переменным, объектам и процедурам. Напомню, [2. стр. 66 -75] для обращения к элементу проекта, на который есть ссылка, необходимо указать его полное имя, включающее имя проекта, имя модуля и собственное имя элемента. В моем примере я буду вызывать процедуру с одним и тем же собственным именем TestPrint, которая есть в обоих подключаемых проектах DocTwo и DocThree. Чтобы вызвать процедуру того проекта, который подключен в текущий момент, очевидно, необходимо организовать разбор случаев. Это нетрудно сделать, зная имя (имена) подключенных проектов. Здесь есть правда некоторый подводный камень. Дело в том, что в соответствующем Case - операторе только имя одного элемента будет определено, того элемента, который принадлежит подключенному проекту, имена вызываемых элементов из других, неподключенных проектов будут неопределены, более того, считаться необъявленными, что немедленно приведет к обычной синтаксической ошибке. Из этой ситуации есть простой выход. Но прежде, чем рассказать о нем давайте взглянем на текст соответствующей процедуры, занимающейся разбором случаев: Public Sub CallProcFromProject() 'Вызов процедуры подключаемого проекта 'Разбор случаев, какой проект подключен If NoP = "DocTwo" Then Proc2 ElseIf NoP = "DocThree" Then Proc3 End If End Sub Public Sub Proc2() 'Вызов процедуры проекта 2 DocTwo.DocTwoModule.TestPrint End Sub Public Sub Proc3() 'Вызов процедуры проекта 2 DocThree.DocThreeModule.TestPrint End Sub В нашей простой ситуации разбором занимается простейший оператор IF, который в зависимости от имени проекта вызывает процедуру TestPrint того или иного проекта. Но заметьте, я не стал в текст этой процедуры вставлять явный вызов процедуры проекта, заменив его на вызов внутренней процедуры, являющейся оберткой настоящего вызова. Таким образом, процедура CallProcFromProject является синтаксически корректной, более того она вызывает синтаксически корректную процедуру, если, конечно, разбор работает корректно. Синтаксически некорректные процедуры не вызываются, их существование в проекте не мешает его нормальной работе. Это, конечно, "уловка", но позволяющая достигнуть заданной цели. Хочу обратить внимание на еще один аспект, связанный с работой этой процедуры. Если Вы заметили эта процедура вызывается в теле процедуры CreateRef, сразу же после создания ссылки на подключаемый проект. Давайте еше раз вернемся к методу AddFromFile, создающему ссылку в коллекции References. Конечно, главным итогом работы этого метода будет не только создание ссылки, но и явное подключение нового документа с его проектом. Это означает, что, если соответствующий документ не был открыт к моменту создания ссылки, то он автоматически откроется. Необходимо иметь в виду еще одно следствие этого процесса,ѕ после завершения процедуры, создающей ссылки в связи с подключением нового проекта, происходит сброс выполнения текущего проекта и, в частности, все глобальные переменные будут обнулены, а следовательно будут потеряны значения переменных, хранящих имена подключаемых проектов. Именно поэтому вызов процедуры CallProcFromProject делается в той же процедуре, в которой новый проект подключается. В противном случае необходимо было повторно запрашивать у пользователя имена подключаемых проектов. В заключение хочу высказать несколько общих замечаний. Прежде всего, следует отметить, что программное подключение и отключение ссылок может быть полезным не только при работе с подключаемыми программными проектами. Список возможных Com - объектов, подключаемых к документу через меню References велик, и зачастую возникает необходимость в программном их подключении. Хочу отметить также, что есть два альтернативных варианта, когда следует создавать систему программных проектов, связанных ссылками. Для первого варианта характерна ситуация, когда из "разных точек общего проекта системы необходимо вызывать одни и те же процедуры", когда есть общий пул данных, с которым работатют все проекты, общие процедуры обработки этих данных. В этом варианте легко спроектировать структуру системы проектов в виде дерева, в корне которого будет проект, содержащий общие данные и процедуры и на который будут ссылаться все остальные проекты. В такой ситуации все ссылки известны на этапе проектирования, их можно установить вручную и никаких проблем нет. Именно этот вариант я подробно рассматривал в [2. гл.2]. Сейчас же рассматривался другой вариант, когда "из одной точки проекта необходимо вызывать разные процедуры". В этом случае программное подключение проектов может быть предпочтительнее. Следует также сказать, что реальная проблема С. Шершнева оказалась сложнее описанной и не укладывается ни в один из двух рассматриваемых вариантов. В его ситуации нельзя было заранее написать процедуру CallProcFromProject, поскольку разбираемые в ней случаи появлялись динамически. Надеюсь, понятно, что выходом в такой ситуации является корректировка кода этой процедуры программно, "на лету" в тот момент, когда появляется новый "случай", новый клиент в системе, создаваемой С.Шершневым. Но, как было показано, сделать это возможно и не так уж и сложно. |
|
|
| ||||||||||||||||
| ||||||||||||||||
| ||||||||||||||||
|