Как избежать межпроцессных вызовов при автоматизации Word через VB.net

Question

Короткая версия У меня есть Word Addin в VB.net и VSTO, который предоставляет COM-совместимый объект через Word.COMAddins.Object, так что функциональность надстройки может называться External to Word, без доступа к самому Word, являющемуся перекрестным процессом.

Техника работала в VB6, но с VB.net она все еще работает, но она намного медленнее, чем тот же код, выполняющийся непосредственно из надстройки через панель задач, как если бы все вызовы были перекрестными, когда они не должны быть. х

Длинная версия Этот плагин, по сути, выполняет тонны обработки документов Word. Аддин может быть запущен двумя способами.

1. из Word, используя панель задач
2. внешне, через набор классов подвергается воздействию COM (потому что я должен предоставить доступ к функционалу в клиентские приложения VB6.

НО, вот руб. Любой, кто когда-либо занимался автоматизацией Word, знает, что код, который прекрасно выполняется INPROC с Word (в данном случае это экземпляр ADDIN, который загружает само Word), обычно будет выполняться неприемлемо медленно из процесса (или кросс-процесса).

Это приложение ничем не отличается.

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

1. Создайте Word Addin как обычно
2. Выставить объект через Свойство Word.COMAddin.Object, которое позволит внешний код получить доступ к вашему Аддин.
3. В вашем внешнем проекте вместо манипулируя Word напрямую, используйте Коллекция Application.COMAddins, найти свой плагин, получить открытое свойство COMAddin.Object от него, а затем вызвать метод на тот объект, который выполняет работу.

Конечно, вызов вашего объекта COMAddin.Object все еще будет кросс-процессным, НО, после выполнения в надстройке, которая находится в ПРОЦЕССЕ с Word, ваш надстройка теперь может выполнять все необходимые ему манипуляции с объектом Word, и это быстро потому что в этот момент все они находятся в процессе вызова.

Это работало в дни COM VB6.

Но я собрал этот VB.net vsto addin и выставил свой объект addin с помощью функции RequestComAddInAutomationService объекта Connect VSTO

Я могу делать вызовы в свой аддин внешне, и все они работают точно так, как я ожидал, за исключением того, что все они + медленные +, очень похоже на то, что вызовы в Word все еще выполняются в кросс-процессе, даже несмотря на то, что код, создающий Обращения к Word является частью dll надстройки, которая была загружена в процессе Word!

И медленно, как примерно в 10 раз; запуск занимает 3 секунды при запуске непосредственно из ADDIN через панель задач, а запуск ~ 30 секунд при вызове из внешнего кода через объект COMADDIN.object.

Я предполагаю, что у меня возникла какая-то проблема с .net APPDOMAINS или чем-то еще, и что + действительно + представляет собой перекрестные вызовы в .net, но я пока не нашел ничего такого, что могло бы даже намекнуть на этот вид вещи.

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

Есть мысли?

Answer 1

Я сделал те же наблюдения с моей надстройкой VSTO Word. Что я хотел бы добавить здесь: Когда вы добавляете свою процедуру в качестве обработчика нажатия для кнопки:

`this.testButton.Нажмите + = new Office._CommandBarButtonEvents_ClickEventHandler (YourProcedure); ´

и реализуйте свою дорогостоящую процедуру в «YourProcedure», вы можете вызвать в поток пользовательского интерфейса Word, используя

this.testButton.Execute ();

Это тоже не элегантное решение, но может быть полезно, если у вас есть кнопки, готовые в CommandBar.

Answer 2

К сожалению, техника ловушек событий, о которой упоминает Торбен, не подойдет для моей конкретной ситуации.

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

Ну, не идеальное решение, но я нашел + + решение. В нем использовался таймер, поэтому он определенно неоптимален. По сути, когда надстройка загружается Word (т.е. во время события STARTUP), инициализируйте таймер (таймер WINFORMS, а не таймер потоков) и установите его интервал равным 500. Когда внешний Код подключается к надстройке через свойство COMADDIN.OBject и выполняет вызов надстройки, устанавливает флаг переменной, который опрашивается таймером. Когда таймер видит, что он установлен, он сбрасывает флаг и выполняет действие.

Это не чистое решение, которое я бы предпочел, но его довольно легко реализовать, умеренно легко понять после факта, и оно определенно позволяет избежать замедления вызовов xprocess COM в Word.