0

短いバージョン VB.netとVSTOにWordAddinがあり、Word.COMAddins.Objectを介してCOM互換オブジェクトを公開します。これにより、Word自体へのアクセスをクロスプロセスせずに、Addin機能をWordの外部で呼び出すことができます。 。

この手法はVB6で機能しましたが、VB.netでも機能しますが、タスクペインを介してアドインから直接実行される同じコードよりもはるかに低速であり、呼び出しがすべてクロスプロセスである必要がないかのようになります。バツ

ロングバージョン このアドインは、基本的にWordドキュメントで大量の処理を実行します。アドインは2つの方法で実行できます。

  1. Word内から、タスクペインを使用して
  2. 外部的には、COMに公開されている一連のクラスを介して（VB6クライアントアプリへの機能へのアクセスを提供する必要があるため）。

しかし、ここにこすりがあります。Wordの自動化を行ったことのある人なら誰でも、Wordで完全に許容範囲内でINPROCで実行されるコード（この場合、Word自体がロードするADDINのインスタンス）は、通常、許容できないほどゆっくりとプロセス外（またはクロスプロセス）で実行されることを知っています。

このアプリも例外ではありません。

何年も前に、私はこの問題を回避するために便利なトリックを利用しました。

  1. 通常どおりWordアドインを作成します
  2. Word.COMAddin.Objectプロパティを介してオブジェクトを公開し、外部コードがアドインにアクセスできるようにします。
  3. 外部プロジェクトでは、Wordを直接操作する代わりに、Application.COMAddinsコレクションを使用して、アドインを見つけ、そこから公開されたCOMAddin.Objectプロパティを取得してから、そのオブジェクトで作業を行うメソッドを呼び出します。

もちろん、COMAddin.Objectオブジェクトの呼び出しはクロスプロセスのままですが、Wordで処理中のアドインで実行が行われると、アドインは必要なすべてのWordオブジェクト操作を実行できるようになり、高速になります。その時点ですべての処理中の呼び出しを再実行します。

それはVB6COMの時代に機能しました。

しかし、私はこのVB.net vstoアドインをまとめ、VSTOのConnectオブジェクトのRequestComAddInAutomationService関数を介してアドインオブジェクトを公開します。

アドインを外部から呼び出すことができます。これらはすべて、期待どおりに機能します。ただし、Wordを呼び出すコードが、Wordを呼び出すコードであっても、Wordへの呼び出しがクロスプロセスで実行されているのと非常によく似ています。 Wordによって処理中にロードされたアドインdllの一部です！

そして、約10対1のように遅くなります。作業ウィンドウを介してADDINから直接実行する場合、実行に3秒かかりますが、COMADDIN.objectオブジェクトを介して外部コードから呼び出される場合、実行に約30秒かかります。

.net APPDOMAINSなどで何らかの問題が発生していて、.netで+実際に+がクロスプロシージャ呼び出しを構成していると推測していますが、これまでのところ、この種のことを示唆するものは何も見つかりませんでした。

私の次のステップは、いくつかの神秘的な洞察を除いて、再現をコード化することです。これは、プレイ中の要素の数が非常に多いため、トリッキーになる可能性があります。

何かご意見は？

4

2 に答える 2

1

VSTO Wordアドインを使用して同じ観察を行いました。ここに追加したいこと：プロシージャをクリックハンドラーとしてボタンに追加する場合：

`this.testButton.Click + = new Office._CommandBarButtonEvents_ClickEventHandler（YourProcedure）;´

高価なプロシージャを「YourProcedure」に実装すると、次を使用してWordのUIスレッドを呼び出すことができます。

this.testButton.Execute（）;

これも洗練されたソリューションではありませんが、コマンドバーにボタンを用意している場合に役立つ可能性があります。

于 2011-04-27T19:24:14.227 に答える
0

残念ながら、ソーベンが言及しているイベントフックテクニックは、私の特定の状況では機能しません。

だから私はコメントで述べた回避策でこの質問を締めくくります、そして私はここで繰り返します...

まあ、完璧な解決策ではありませんが、私は+a+の解決策を見つけました。タイマーが含まれているため、間違いなく最適ではありません。基本的に、アドインがWordによって読み込まれるとき（つまり、STARTUPイベント中）、タイマーを初期化し（スレッドタイマーではなく、WINFORMSタイマー）、間隔を500に設定します。コードはCOMADDIN.OBjectプロパティを介してアドインに接続し、アドインを呼び出し、タイマーによってポーリングされている変数フラグを設定します。タイマーはそれが設定されていることを確認すると、フラグをリセットしてアクションを実行します。

これは私が好んだクリーンなソリューションではありませんが、実装はかなり簡単で、事後に適度に理解しやすく、WordへのxprocessCOM呼び出しの速度低下を確実に回避します。

于 2012-07-03T15:28:30.757 に答える