代码之家 › 专栏 › 技术社区 › DarinH

在通过图书管理系统

cross-process com-interop ms-office vb.net

0

DarinH · 技术社区 · 16 年前

短版我有话要说VB.net版和VSTO,它通过Word.COMAddins.Object对象,以便可以在Word外部调用addin功能,而不必跨进程访问Word本身。

这项技术在VB6中工作,但是图书管理系统,它仍然可以工作,但比通过任务窗格直接从加载项运行的同一代码慢得多,好像调用都是跨进程的,而不应该是跨进程的。十

长版这个加载项本质上对Word文档进行大量的处理。加载项可以通过两种方式运行。

在Word中,使用任务窗格
外部,通过一组类接触COM(因为我必须提供对功能的访问到VB6客户端应用程序。

但是,这就是问题所在。任何完成过Word自动化的人都知道,在proc中与Word一起运行的代码(在本例中是Word本身加载的ADDIN实例)通常会在进程外(或跨进程)缓慢地运行,这是不可接受的。

这个应用程序也一样。

很久以前,我用了一个简单的技巧来回避这个问题。

像往常一样创建单词Addin
通过 Word.COMAddin.Object对象财产将允许外部代码访问艾丁。
在外部项目中,而不是直接操纵单词,使用应用程序.COMAddins收藏, 找到你的加载项,检索暴露的COMAddin.对象财产然后调用做工作的那个物体。

当然,你的电话COMAddin.对象对象仍然是跨进程的,但是,一旦在Word正在处理的加载项中执行,您的加载项现在可以执行它想要的所有Word对象操作,而且速度很快,因为它们都是在处理时调用的。

在VB6 COM时代起作用了。

但是,我把这个VB.net版vsto addin,并通过vsto的Connect对象的RequestComAddInAutomationService函数公开我的addin对象

我可以在外部调用我的加载项,它们的工作方式与我预期的完全一样,只是它们都是+慢速+,非常像对Word的调用仍然是跨进程执行的,即使对Word进行这些调用的代码是Word加载的加载项dll的一部分!

并以大约10到1的倍数减慢;当通过任务窗格直接从加载项运行时,需要3秒运行;当通过任务窗格从外部代码调用时,需要大约30秒运行COMADDIN.对象反对。

我猜我在.net APPDOMAINS或其他东西上遇到了一些问题,+really+构成了.net中的跨过程调用,但是到目前为止,我还没有发现任何东西可以暗示这类事情。

我的下一步,除了一些神秘的见解,将是编码一个重发,这可能会变得棘手,因为在发挥的元素的剪切数。

有什么想法吗?

2 回复 | 直到 11 年前

1

Thorben Ziemek 15 年前

我对我的VSTO Word插件也做了同样的观察。我想在此添加的内容:当您将过程作为单击处理程序添加到按钮时:

`this.testButton.Click+=新建办公室。单击事件处理程序(您的过程);

在“your procedure”中实现昂贵的过程,可以使用

this.testButton.Execute执行();

这也不是一个优雅的解决方案,但如果您碰巧在命令栏中准备好了按钮,则可能会很有用。

2

0

DarinH 14 年前

不幸的是,索本提到的事件钩子技术不适合我的特殊情况。

所以我用我在评论中提到的解决方法来结束这个问题,我将在这里重复。。。

嗯,不是一个完美的解决方案,但我找到了+a+解决方案。它包含一个计时器,所以它本质上绝对是次优的,当加载项由Word加载时(即在启动事件期间),初始化一个计时器(WINFORMS计时器,而不是线程计时器),并将其间隔设置为500。当外部代码通过COMADDIN.对象属性,并调用加载项,设置由计时器轮询的变量标志。当计时器看到它被设置时,它重置标志并执行操作。

这不是我想要的干净的解决方案,但它相当容易实现,事后也相当容易理解,而且它绝对避免了xprocess COM调用到Word的速度减慢。