Как подключить офис к visual studio
Поддержка создания решений на основе Microsoft Office появилась в Visual Studio в 2003 году: первая версия Visual Studio Tools for Office поддерживала только Excel 2003 и Word 2003 и позволяла реализовывать расширения на уровне документов (document-level code behind), используя управляемый код.
В VSTO 2005 появилась поддержка InfoPath, а также возможность создания модулей расширения для Outlook. Помимо этого в VSTO 2005 была реализована поддержка создания панелей задач (ActionsPane) для ряда продуктов, входящих в семейство Microsoft Office 2003.
В VSTO 2005 Second Edition была добавлена поддержка Office 2007, включая возможность создания расширений для PowerPoint и Visio. Этот продукт был доступен для бесплатной загрузки для легальных пользователей Microsoft Visual Studio.
Как уже было отмечено, VSTO 3.0 входит в состав Visual Studio 2008 начиная с версии Professional и обеспечивает поддержку разработки модулей расширения на уровне документов и приложений как для Office 2003, так и для Office 2007. Обеспечены возможность создания Workflow для Microsoft SharePoint и развертывание по технологии ClickOnce.
Основные требования
Для того чтобы вы смогли создавать решения с помощью Visual Studio Tools for Office, на компьютере, используемом для разработки, должны быть установлены следующие компоненты:
Для установки Visual Studio Tools for Office на компьютере, где планируется разработка для Microsoft Office System 2007, необходимо выполнить следующие шаги:
Если вы планируете создавать и расширять SharePoint Workflow, необходимо установить Visual Studio Tools for Office на компьютере, операционная система которого поддерживает Microsoft Office SharePoint Server 2007 — Windows Server 2003 или Windows Server 2008. В результате будут установлены шаблоны проектов, которые позволят вам создавать расширения для SharePoint Workflow.
После того как все необходимые компоненты, продукты и средства разработки установлены, можно приступать к разработке решений на базе Microsoft Office. К основным возможностям, предоставляемым Visual Studio Tools for Office, относятся: создание дополнительных модулей, работа с документами Word и Excel, расширение интерфейсного элемента «лента», создание панелей задач, использование Word Content Controls, разработка расширения на основе Outlook Forms и создание расширений для SharePoint Workflow.
Создание дополнительных модулей
Дополнительные модули на уровне приложений (application-level add-ins) позволяют расширять функциональность ключевых приложений, входящих в состав Microsoft Office. Дополнительные модули доступны в приложении независимо от того, какой документ в нем открыт, — это отличает механизмы расширения на основе дополнительных модулей от механизмов расширения на основе шаблонов документов, которые мы рассмотрим ниже.
В Visual Studio Tools for Office входят средства для создания дополнительных модулей на основе новых шаблонов проектов для большинства приложений, входящих в семейства Microsoft Office 2003 и Microsoft Office 2007, — Excel 2003 и 2007, InfoPath 2007, Outlook 2003 и 2007, PowerPoint 2003 и 2007, Project 2003 и 2007, Visio 2003 и 2007, Word 2003 и 2007. Использование новой программной модели существенно упрощает создание дополнительных модулей, так как не требует применения COM-технологий.
Шаблоны, входящие в состав Visual Studio Tools for Office
Среди новинок для модулей расширений отметим возможность обеспечения доступа к объектам внутри ваших моделей расширений из других компонентов Microsoft Office — например из других модулей расширений или из кода на Visual Basic for Applications, включенного в состав документа. Таким образом, у разработчиков появляется возможность создания на уровне модулей расширения разделяемых сервисов, которые могут использоваться другими компонентами и сервисами.
Работа с документами Word и Excel
Создание расширений на уровне документов представляет собой способ добавления расширенной функциональности к тому или иному документу либо к электронной таблице. Поскольку расширения реализованы на уровне документов, они будут доступны только в тех документах или электронных таблицах, с которыми они ассоциированы.
В состав Visual Studio Tools for Office входит набор возможностей, упрощающих создание расширений на уровне документов для Word 2007 и Excel 2007. К таким возможностям относятся:
- создание расширений для документов и электронных таблиц в формате Office Open XML для Word 2007 и Excel 2007 или в двоичных форматах, поддерживаемых в Microsoft Office 2003 или более ранних версий;
- дизайн документов и шаблонов в Visual Studio и написание кода в среде разработчика;
- возможность добавления компонентов Windows Forms в документы и шаблоны;
- добавление компонентов-расширений (host-controls) для встроенных объектов Word и Excel, которые расширяют объектный модуль и обеспечивают возможность связи с данными.
Настройка и расширение «ленты»
Интерфейсный элемент «лента» (Ribbon) впервые появился в Microsoft Office 2007 и представляет собой объединение функциональных возможностей меню, списков, галерей и ряда других элементов. Лента поддерживает контекстное переключение, группировку задач и ряд других возможностей. В Microsoft Office 2007 поддерживаются программная настройка и расширение интерфейсного элемента «лента» для продуктов Microsoft Office Excel 2007, Microsoft Office Outlook 2007, Microsoft Office PowerPoint 2007 и Microsoft Office Word 2007.
Существует два способа настройки элемента «лента»: с помощью дизайнера Ribbon Designer, включенного в состав Visual Studio Tools for Office 2008, и через описание «ленты» на языке Ribbon XML.
Настройка элемента «лента» с помощью дизайнера поддерживает следующую функциональность:
- возможность добавления настраиваемой «ленты» к проекту Office с применением специального шаблона проекта — Ribbon (Visual Designer);
- визуальное создание новых вкладок с помощью дизайнера:
- перетаскивание компонентов на «ленту»,
- настройка расположения компонентов и их внешнего вида,
- добавление обработчиков событий двойным щелчком по компоненту «ленты»;
Дизайнер также может использоваться для добавления компонентов к меню, которые открываются при нажатии на кнопку Office (Microsoft Office Button).
Настройка «ленты» с применением языка Ribbon XML позволяет более детально контролировать «ленту» и ее элементы и выполнять ряд задач, не поддерживаемых в дизайнере Ribbon Designer. В Visual Studio Tools for Office 2008 работа с «лентой» на уровне Ribbon XML поддерживается на уровне специального шаблона — Ribbon (XML), помимо этого имеется возможность экспорта любой «ленты», созданной средствами дизайнера, в шаблон для редактирования «ленты» на уровне языка XML.
В Visual Studio Tools for Office 2008 реализована типизованная объектная модель, которая может использоваться для управления компонентами «ленты» в режиме выполнения приложения. Например, можно динамически добавлять элементы меню или управлять отображением отдельных компонентов в зависимости от контекста, в котором в данный момент находится приложение. Объектная модель состоит из трех ключевых элементов: класса Ribbon, событийной модели и классов, отвечающих за отдельные компоненты «ленты».
Класс Ribbon наследует от класса OfficeRibbon и представляет собой класс, код которого разделен в файлах кода, создаваемого разработчиком, и файла, генерируемого дизайнером «ленты». Событийная модель поддерживает три события: Load, возникающее при начальной загрузке расширений «ленты», LoadImage, используемое для кэширования графических изображений, применяемых в «ленте», и Close, которое возникает при завершении работы экземпляра «ленты».
В пространстве имен Microsoft.Office.Tools.Ribbon определены следующие классы, отвечающие за отдельные компоненты «ленты» (табл. 2).
Каждый класс отвечает за отдельный тип компонента «ленты» и свойства, которые позволяют динамически управлять отображением компонента и рядом других его параметров. Помимо свойств каждый компонент «ленты» поддерживает ряд событий — они перечислены в табл. 3.
Все рассмотренные выше классы, события и другие элементы поддержки «ленты» в Visual Studio Tools for Office 2008 реализованы в пространстве имен Microsoft.Office.Tools.Ribbon. Здесь содержатся классы приведенные в табл. 4.
Создание панелей задач
Создание панелей задач — это еще один способ настройки приложений Microsoft Office с помощью Visual Studio Tools for Office 2008. Панели задач представляют собой интерфейсный элемент, который обычно располагается справа от основного окна приложения Microsoft Office. Панели задач позволяют расширять функциональность офисных приложений и часто используются как механизм обеспечения интеграции между офисными приложениями и приложениями, автоматизирующими какие-либо бизнес-задачи.
Панели задач обычно создаются либо на уровне документов (в этом случае они называются Actions Panes), либо на уровне приложений — в таком случае их называют Custom Task Panes. В табл. 5 приведены основные рекомендации по использованию Actions Panes и Custom Task Panes.
В этом разделе содержатся подразделы, позволяющие начать работу со средствами разработчика для Microsoft Office в Visual Studio.
Интересуетесь разработкой решений, расширяющих возможности Office на нескольких платформах? Ознакомьтесь с новой моделью надстроек Office. Надстройки Office имеют небольшой объем по сравнению с надстройками и решениями VSTO, и их можно создавать с помощью практически любой технологии веб-программирования, такой как HTML5, JavaScript, CSS3 и XML.
Содержание раздела
Общие сведения о разработке решений Office в Visual Studio.
Описание приложений и проектов, необходимых для использования таких функций разработки приложений Office, как расширяемость ленты, настраиваемые панели задач, панели действий и области формы.
содержит сведения и инструкции по установке средств разработки Office, среды выполнения, которая позволяет Officeным решениям запускаться на компьютерах конечных пользователей и Office основных сборках взаимодействия.
Обзор важных понятий, необходимых для создания настроек уровня документа для Excel в Visual Studio.
Обзор важных понятий, необходимых для создания настроек уровня документа для Word в Visual Studio.
Обзор важных понятий, необходимых для создания надстроек VSTO (Visual Studio Tools for Office) уровня приложения для приложений Microsoft Office в Visual Studio.
Описание сравнительных преимуществ набора средств Visual Basic для приложений и средств разработки Office в Visual Studio при разработке решений Office.
Ссылки на разделы, которые могут помочь в решении общих проблем.
Связанные разделы
Ссылки на примеры приложений и разделы с пошаговыми инструкциями по выполнению типовых задач.
описание компонентов Office решений и их работы во время разработки и выполнения.
Инструкции по созданию и настройке проектов Office в Visual Studio.
Инструкции по реализации кода и настроек пользовательского интерфейса в проектах Office.
Сведения о требованиях безопасности для решений Office.
Инструкции по предоставлению доступа к решению Office для пользователей и описание основных вопросов, связанных с выбором метода развертывания и настройкой параметров безопасности.
метод добавления ссылки на COM-взаимодействие Office в Visual Studio заключается в следующем:
- ссылки
- Добавить Ссылку
- выберите COM tab
- выберите Библиотека Объектов Microsoft Office 11.0
и появляется волшебно названная ссылка:
на Project.csproj файл показывает детали ссылка:
и проект проверяется в системе управления версиями, и все хорошо.
затем разработчик с Office 2007 получает проект из системы управления версиями и не может его построить, потому что такой ссылки не существует.
он (то есть я) проверяет .csproj файл, удаляет ссылку на
и повторно добавляет ссылку COM Как
и магически именованная ссылка появляется:
на Project.csproj файл показывает детали ссылки:
и проект проверяется в системе управления версиями, и все хорошо.
затем разработчик с Office 2003 получает проект из системы управления версиями и не может его построить, потому что такой ссылки не существует.
он (то есть не я) проверяет .csproj файл, удаляет ссылку на
и повторно добавляет ссылка COM Как
и волшебным образом появляется именованная ссылка:
на Project.csproj файл показывает детали ссылки:
и проект проверяется в системе управления версиями, и все хорошо.
затем проект строится, нажимается на CDs, и послал к клиентам,Office 2007.
и не все хорошо.
что соответствует clsid установленного офиса, например
из которых класс затем строится с помощью вызова COM (язык - netural псевдо-код):
вопросы
1) каков утвержденный метод автоматизации установленного офиса заявления?
3) Если я использую основные сборки взаимодействия Office 2003, должен ли я установить office 2003?
4) Если я создаю с основными сборками взаимодействия Office 2003, мои клиенты привязаны к Office 20003 навсегда?
5) Есть ли Office 2007 Основные Сборки Взаимодействия?
6) Если я устанавливаю основные сборки взаимодействия Office 2007, должен ли я установить Office 2007?
7) что не так с использованием стандартного com-взаимодействия для управления Excel, Word или Outlook? например:
8) чего вы достигаете, когда добавляете
Вау, это огромное количество вопросов. Я думаю, что в целом, если ваше приложение использует PIAs, вы предполагаете, что у вашей целевой аудитории установлена какая-то версия Office. PIAs будет установлен в GAC, когда целевой пользователь установит Office. Если у них не установлен Office, почему вы нацелены на Office?
да, библиотеки DLL Office-это правильный способ автоматизации Office. Вот список сборок здесь, в том числе для офиса 2007.
ответ заключается в том, чтобы" скопировать локальную " любую dll сборки, которую вы получаете для взаимодействия. После того, как у вас есть dll сборки в выходной папке, добавьте ссылку на него и проверьте его в системе управления версиями.
теперь у всех есть ссылочная сборка dll.
используете ли вы VSTO (Visual studio tools for office)?
старая нить, и, вероятно, большинство людей были бы довольны CopyLocal=True, однако вот другой способ.. Использовать и (или больше. мышление Office 2010, если проблема все еще существует..) ссылки в ваших файлах проекта и либо игнорировать, либо просто сказать MSBuild игнорировать предупреждение "MSB3284" (библиотека не найдена). Так что включи это в свой .файл csproj:
мне было бы интересно узнать, предоставляет ли Microsoft NuGet библиотека для этого - просто, чтобы все на один подход. Я думаю, что это устранит необходимость для людей искать в интернете эти ответы. Я считаю, что это будет против лицензии Microsoft Office, поэтому они единственные, кто ее предоставит.
BTW с copy local вы должны быть осторожны, чтобы не распространять эту библиотеку по ошибке.
В статье приведена инфраструктура Windows Forms проекта, в котором Microsoft Word воспринимается приложением в качестве шелла. В статье раскрыты несколько интересных моментов использования Composite UI Application Block, в частности подключение инфраструктуры доменной модели Word в сервисам расширения каркаса, а так же приведены некоторые факты и особенности разработки с использованием средств VSTO.
Задача
Предположим, у нас есть несколько десятков людей, которые пишут документы и постоянно работают с их редакциями. Sharepoint и другие порталы по каким-то причинам не подходят, поэтому требуется реализация собственной бизнес-логики. Усложним задачу — люди работают в области, очень далекой от компьютерной тематики и хорошо знают только пакет Microsoft Office. Еще усложним — контора бедная, Microsoft Office у большинства народа версии 2003-ей. Кое где, у больших начальников и Главного босса стоит 2007ой. Парк машин разнородный — начиная от 2000-ой винды и до Windows Vista.
Решение
А к чему все это?
(Это кому не терпиться узнать, чем все закончится). На выходе я выложу Visual Studio solution, который позволит в полпинка создать свое приложение, подключаемое в Microsoft Word. По ходу дела я объясню практически все, что и как в этом солюшене используется.
Что потребуется для работы
- Microsoft Word 2003 SP3
- Visual Studio 2005 или 2008
Зачем CAB?
Для того, чтобы определить явное разделение функционала, связанного с Microsoft Word от простой Windows Forms логики. Проще говоря, наш плагин будет являться модулем CAB, и при желании, мы легко сможем подключить эту логику в другие приложения CAB. Еще проще говоря, использование CAB минимизирует количество glue-кода.
Есть еще две причины, по которым я включил CAB в решение. Первая состоит в том, что я уже давал описание этого каркаса здесь, а теперь хочу привести полноценный работающий пример. Вторая причина более банальная — мне нравится CAB, он делает мир и вещи в нем проще:)
Подробнее про VSTO
- Уровень документа (Document Level Customization)
- Уровень приложения (Application Level Customization)
Если кто заинтересовался возможностями VSTO — очень много про них есть в msdn.
Псевдозадача
Создадим маленький пример, иллюстрирующий все вышесказанное. Пусть есть требование, согласно которому пользователь может выделять текст из документа Microsoft Word и получать этот выделенный текст в окошке пользовательского элемента (знаю, дурацкий пример, но более сложного делать не хочется, а менее сложный уже трудно придумать).
Более подробно. Пользователь запускает Microsoft Word. После запуска среди тулбаров пользователю будет доступен ТР — тулбар расширения (т.е., нашего расширения). На нем находится кнопка, по нажатию которой пользователю показывется окно с кнопкой «Получить текст» и элементом управления multiline textbox. Пользователь нажимает на кнопку «Получить текст», выделенный в документе текст копируется в textbox. Все счастливы.
Понятно, что для жизни пример малопригоден. Но создаваемая инфраструктура позволит довольно просто нарастить на него «мускулы», если это, конечно, кому-то потребуется.
Создание solution
После установки VSTO в студии при создании нового solution станут доступны Office проекты:
Будьте аккуратны с названием — оно одновременно будет являться названием root namespace и поменять его можно будет только ручками через выгрузку проекта.
На выходе получается солюшен с двумя проектами:
WordCAB — это, собственно, add-in. Второй — не менее важный, это deployment проект для модуля расширения. Почему он важен?
Дело в том, что установка модуля расширения на рабочие станции пользователей — весьма трудоемкая затея. Она заключается не только в том, чтобы просто скопировать библиотеки в нужную папку. Для успешного фукнционирования модуля требуется прописать кучу ключей в реестр. Если копнуть глубже, получается, что модуль расширения подключается к Microsoft Office как COM-библиотека, со всеми вытекающими. Кому интересно, все нужные ключи реестра можно поглядеть в deployment-проекте (Нажать правой кнопкой, View->Registry).
В классе ThisAddIn находится точка доступа в модуль:
private void ThisAddIn_Shutdown( object sender, System. EventArgs e)
>/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InternalStartup()
this .Startup += new System.EventHandler(ThisAddIn_Startup);
this .Shutdown += new System.EventHandler(ThisAddIn_Shutdown);
>* This source code was highlighted with Source Code Highlighter .
В ThisAddIn_Startup будем писать код. Если быть точнее, будем запускать CAB-приложение.
Что такое CAB-приложение?
Это класс такой. В нем есть точка запуска — метод Run() , и некоторая инфраструктура каркаса — в частности, имеются доступ к главному прецеденту «Приложение» (т.е., к основному, рутовому WorkItem) и возможности переопределить системные сервисы, добавляемые в приложения по-умолчанию. Этот класс уже реализован в базовом виде, а программисту требуется параметризировать его — указать тип рутового прецедента и тип главной формы:
internal sealed class AddInApplication : WindowsFormsApplication<AddInWorkItem, object >
protected override void Start()
>
>* This source code was highlighted with Source Code Highlighter .
В качестве типа главной формы (шелловой формы), указан object. Почему? Потому что приложение запускается в Microsoft Word, поэтому необходимости создавать главную форму нет. Форма Microsoft Word и есть главная форма, правда, без традиционных для нее возможностей.
По ходу пьесы мне пришло в голову немного прояснить модель приложения для модуля расширения в Microsoft Word.
Модель приложения Word Add-in
Итак, пользователь работает с документами. Более того, в единицу времени он может работать только с одним документом. Поэтому модуль расширения имеет четкий контекст — текущий открытый документ. (Кстати, в модели Microsoft Word VSTO этот документ обозначен как Globals.ThisAddIn.Application.ActiveDocument ). Отсюда (я сделал) вывод (или упрощение) — показывать пользовательские бизнес-элементы имеет смысл в модальном режиме, поскольку в ином случае нарушается контекст. Элементы управления, открытые для одного документа, должны существовать только во время активности этого документа.
Пример — пользователь открыл документ и открыл его карточку (не в модальном режиме). Переключился на другой документ, а карточка осталась для предыдущего — нарушение контекста и целостности восприятия. Разумеется, подобное поведение контролировать можно (и даже нужно, в некоторых случаях), но модальность элементов управления и жесткая их привязка к текущему активному документу делает жизнь проще.
Modal Workspace
Пользовательские элементы управления в каркасе CAB показываются в специальных так называемых рабочих зонах (Workspace). Согласно описанному выше поведению, нам требуется показывать элементы управления в модальном режиме. Поскольку родной CAB-овский WindowWorkspace оказался дубоват и выглядит некрасиво, я написал простенький свой — приводить код не буду, потому что его пара-тройка экранов. Насладиться творчеством можно скачав solution с кодом (ссылка на архив приведена в конце статьи).
Workspaces.Add(( new SimpleModalWorkspace() ), WorkspaceNames.MainWorkspace);
* This source code was highlighted with Source Code Highlighter .
Итого: под ключем-идентификатором WorkspaceNames.MainWorkspace зарегистрировали модальную рабочую зону. Доступиться до нее теперь можно откуда угодно, где есть ссылка на главный прецедент: запрос интерфейса IWorkspace из коллекции Workspaces по указанному выше ключу. Все просто, как апельсин! (с) х/ф «Терминатор 2»
Фабрика элементов управления Microsoft Word
Речь пойдет о тулбаре Word и кнопках на нем. В VSTO это обертки над COM-объектами — CommandBar и CommandBarButton из пространства имен Microsoft.Office.Core . Жутко глючные штуки, если честно, особенно их анимация. Понять все тонкости и детали удалось только после ударного троллинга на форумах VSTO.
В чем идея — идея состоит в том, чтобы избавить программиста и разработчиков бизнес-модулей от необходимости работать с COM-обертками. Для этого, мы (то есть, я) интегрируем модель Misrosoft Word в механизм так называемых мест расширения (UiExtensionSite) каркаса CAB.
- В массив тулбаров Microsoft Word вставляется тулбар
- В коллекцию кнопок на тулбаре вставляется кнопка
- В кнопку уже ничего не вставляется (не рассматриваем случае комбобоксов, хотя они присутствуют), поэтому это терминальный объект
- IWordCommandBarContainer — контейнер тулбаров Microsoft Word
- IWordCommandBar — контейнер кнопок на тулбаре
- IWordButton — кнопка
К слову сказать, помимо определения элементов управления Word конкретные типы интерфейсов IWordCommandBar и IWordButton являются адаптерами к упомянутым выше CommandBar и CommandBarButton соответственно.
Для того, чтобы каркас понял, что, куда и, главное, каким образом вставлять, ему необходимо зарегистировать фабрику адаптеров для пользовательских элементов управления. В нашем случае, вставлять можно тулбары (в коллекцию тулбаров) и кнопки (в коллекцию кнопкок на тулбаре). Поэтому, регистрировать фабрику адаптеров нужно для IWordCommandBarContainer и для IWordCommandBar . Потом, когда пользователь будет получать место расширения, каркас будет искать инстансы классов добавления подчиненных элементов для этого места расширения, после чего использовать их по назначению — добавлять элементы. Ну а чтобы не заморачиваться, эти инстансы порождаются фабрикой:
public class CommandBarUIAdapterFactory : IUIElementAdapterFactory
public IUIElementAdapter GetAdapter( object uiElement)
if ( uiElement is IWordCommandBarContainer ) //тулбары
return new CommandBarUIAdapter(( IWordCommandBarContainer )uiElement);
if ( uiElement is IWordCommandBar ) //кнопки в тулбарах
return new CommandBarButtonUIAdapter(( IWordCommandBar )uiElement);throw new ArgumentException( "uiElement" );
>public bool Supports( object uiElement)
return ( uiElement is IWordCommandBarContainer ) || ( uiElement is IWordCommandBar );
>
>* This source code was highlighted with Source Code Highlighter .
А вот реализация коллекции тулбаров (с возможностью добавить новый!)
private object _null = System.Reflection.Missing.Value;
* This source code was highlighted with Source Code Highlighter .
С кнопками на тулбарах аналогично. Гляньте код на досуге.
Пришлось, к слову, создавать фабрику самих кнопкок и тулбаров (см. IWordUIElementFactory ). Дело в том, что модули CAB работают с интерфейсами IWordCommandBar и IWordButton . Конкретные типы этих интерфейсов находятся в сборке VSTO Word-AddIn и завязаны на Microsoft.Office.Core . Поэтому, чтобы в модулях (где отсутствует ссылка на Office) была возможность получать инстансы указанных элементов, создается фабрика. Она регистрируется в главном WorkItem.
Services.AddNew<WordUIElementFactory, IWordUIElementFactory>();
IUIElementAdapterFactoryCatalog factoryService = base .Services.Get<IUIElementAdapterFactoryCatalog>();
factoryService.RegisterFactory( new CommandBarUIAdapterFactory());UIExtensionSites.RegisterSite(UIExtensionSiteNames.WordBarsSite, new BarCollection());
* This source code was highlighted with Source Code Highlighter .
Если вы запутались, извините:) Я сам понимаю, что тут без поллитры не разберешься. (Если подебажиться, то многое становится понятным.)
Модуль CAB
Это обычная сборка. В ней должен быть класс ModuleInit . В этом классе есть ссылка на главный прецедент AddInWorkitem и, как следствие, есть доступ ко всему добру, про которое я писал выше.
Задача модуля CAB такова — подгрузиться к главному преценденту, вставить тулбар, вставить кнопку на него, описать обработчик кнопки:
UIExtensionSite site = _rootWorkItem.UIExtensionSites[UIExtensionSiteNames.WordBarsSite];
IWordCommandBar mainBar = site.Add<IWordCommandBar>(_factory.CreateBar( "AddInToolbar" ));IWordButton btn = _factory.CreateButton(mainBar, CommandNames.OpenForm, ToolStripItemDisplayStyle.ImageAndText, "Открыть окно" ,
"Открыть форму просмотра Custom Control" , Resources.OpenForm, false );mainBar.AddButton(btn);
btn.Click += new EventHandler<WordButtonClickArgs>(ButtonClick);* This source code was highlighted with Source Code Highlighter .
Обработчик кнопки будет создавать пользовательское окно с кнопкой «получить текст» и текстовым полем, после чего показывать его (применив специальный модификатор показа WindowSmartPartInfo ) в ранее упомянутой рабочей зоне (которую, как мы помним, я зарегистрировал в прецеденте под ключем WorkspaceNames.MainWorkspace ):
private void ButtonClick( object sender, WordButtonClickArgs e)
object smartPart = _rootWorkItem.SmartParts.AddNew<SampleSmartPart>();
WindowSmartPartInfo info = new WindowSmartPartInfo();
info.FormStartPosition = FormStartPosition.CenterScreen;
info.MaximizeBox = false ;
info.MinimizeBox = false ;
info.Resizable = false ;
info.Title = "Custom Control" ;
info.ShowInTaskbar = false ;
_rootWorkItem.Workspaces[WorkspaceNames.MainWorkspace].Show(smartPart, info);
>* This source code was highlighted with Source Code Highlighter .
Подгрузка модуля
Здесь я сделал финт коленом. Обычно модули подгружаются в каркас через специальный декларативный формат подгрузки — так называемый ProfileCatalog. Обычно, это хороший способ подключить все, что нужно. Но, учитывая суровые советские реалии, имеется ненулевая вероятность того, что программисту потребуется недекларативная логика подключения модуля. Для этого мы будем переопределять специальный сервис перечисления подгружаемых модулей — IModuleEnumerator . Я сделал его очень простым — он глядит в папку исполняемой сборки и ищет в ней модуль под названием CustomModule.dll. Находит, и подгружает. Ну, или не подгружает, если не находит:
public IModuleInfo[] EnumerateModules()
List <IModuleInfo> result = new List <IModuleInfo>();string path = GetModulePath(ModuleName);
if ( File .Exists(path) )
result.Add( new ModuleInfo(ModuleName));
return result.ToArray();
>* This source code was highlighted with Source Code Highlighter .
Сейчас эта служба очень простая, но при желании, разумеется, в нее можно нагородить хоть черта лысого. Например, подгружать модули из базы данных:)
Перегрузить эту службу нужно в классе приложения CAB:
protected override void AddServices()
base .AddServices();RootWorkItem.Services.Remove<IModuleEnumerator>();
RootWorkItem.Services.AddOnDemand<CustomModuleEnumerator, IModuleEnumerator>();
>* This source code was highlighted with Source Code Highlighter .
Доктор, я устал. Что получилось?
Получилось то, что задумывалось в изначальном псевдопримере:
В тулбарах Microsoft находится наш тулбар, на нем висит кнопка с иконкой, по событию нажатия кнопки вылезает пользовательский элемент управления, в текстовое поле которого с помощью кнопки можно загнать выделенный в документе текст:) Тривиально, но обратите внимание, как ничтожна связность между объектами! Хочется подметить, что у каркаса, при должном обращении, идеальная code maintainability.Внимание! Подводные камни!
Security
The operation you are performing will alter security policy.
Are you sure you want to perform this operation? (yes/no)
yes
Added union code group with "-url" membership condition to the User level.
SuccessВместо "D:\Projects\WordCAB\bin\Debug\*" нужно указать папку, из которой производится запуск Add-in. Не забудьте про звездочку.
Add-in перестал загружаться!
Иногда, когда в модуле возникает необработанный Exception, Word блокирует исполнение этого модуля при следующей загрузке. Зайдите Help->About->Disabled Items и посмотрите, нет ли в списке вашего расширения. Если есть, уберите его оттуда. При следующем Run-Debug он появится.
Как убрать
Удаление расширения не такое тривиальное. Вытащите кнопку COM-AddIns на тулбар Microsoft Word. Для этого надо зайти в Tools->Customize->Tools->(Drag'n'Drop)COM-AddIns. Кликните на нее и снимите галку с вашего расширения. Он выгрузится. Чтобы заново подгружать, наоборот, выставите галку обратно. Другой способ — зайти в панель управления и удалить из программ.
А что с Word 2007?
Add-in замечательно подгружается в Ribbon на последнюю вкладку.
Там еще кучка мелких подводных камней. Но я тут и так уже настолько много написал, что не уверен, что кто-нибудь до конца дочитает:)
Использование Visual Studio для Excel Разработка расширений VSTO: инструкции и основные операции
Excel должен быть эффективным инструментом, который мы обычно используем в нашей повседневной работе. Если вы хотите расширить больше бизнес-функций Excel, вы можете разработать расширения VSTO для Excel в среде разработки VS. Интерфейс Excel, после добавления вкладок и элементов управления в функциональную область Office, выполняет некоторые необходимые нам бизнес-функции:
Новая надстройка Excel VSTO
Создайте новое приложение расширения Excel в VS. Если вы не найдете эту опцию, перейдите к установщику VS в красном поле и выберите вариант разработки Office (версия VS, которую я использую - 2015 и 2017)
ThisAddIn.cs является основной точкой входа в программу расширения VSTO, которая предоставляет нам множество событий обратного вызова для использования
Щелкните правой кнопкой мыши в решении нового проекта, чтобы создать функциональную область для проекта Excel, эта функциональная область является пользовательским интерфейсом внешней программы Excel VSTO.
Основные пространства имен и абстрактные типы
Узнайте о двух часто используемых библиотеках
При разработке VSTO часто используются две библиотеки:
Понимать абстрактные типы в разработке Excel
1、Application
В программе VSTO интерфейс приложения представляет все приложение Excel
2、WorkSheet
Объект WorkSheet является членом набора объектов WorkSheets и является абстракцией страницы листа в Excel.
3、Range
Объект Range - это абстракция каждой ячейки в Excel или выделенной области, содержащей один или несколько блоков ячеек (эта область может быть непрерывной или прерывистой) )
Вышеупомянутые три элемента - три наиболее часто используемых абстрактных интерфейса для Excel в VSTO
Основная операция
В проекте Excel, в файле ThisAddIn и других файлах проекта,Способ чтения и записи элементов Excel отличается:
- В файле ThisAddIn.cs получить доступ к элементам в Excel и получить прямой доступ к нему с помощью приложения
- Однако в файлах не-ThisAddIn .cs, таких как событие кнопки новой ленты, если вы хотите получить доступ к элементу Excel, вы должны добавить Globals.ThisAddIn впереди, чтобы получить к нему обычный доступ.
- При нормальных обстоятельствах бизнес-операции вообще не будут выполняться в основной программе, поэтому все основные примеры операций в будущем будут приведены в соответствии с методом доступа неосновной программы:
Расширенные элементы управления Excel
Microsoft предоставляет несколько полезных расширенных элементов управления для Excel, которые могут помочь Excel выполнить более расширенные функции, такие как:
- Добавить таблицу на лист и связать источник данных
- Добавить диаграмму на лист и связать источник данных
- Подождите, как показано ниже:
1. Используйте ObjectList, чтобы расширить элемент управления на таблицу Excel и связать источник данных
Все операции, описанные выше, являются операциями над каждым отдельным элементом в Excel, но если есть одинисточник данныхНеобходимо связать с рабочим листом в Excel, это роль ListObject. Элемент управления ListObject поддерживает простое и сложное связывание данных, самое простое, например: например, связывание источника данных DataTable в памяти
Вариант использования 1: привязка DataTable к ObjectList
Добавление ListObject в WorkSheet of Excel с использованием программирования VSTO аналогично добавлению таблицы в Excel. Операция в Excel заключается в следующем:
Читайте также: