2012-03-14 12 views
1

C#VSTOアドインプロジェクトでは、ドキュメント構造を追跡するためにWordコントロールにコンテンツコントロールを追加しています。コンテンツコントロールを使用して、ドキュメントのさまざまな要素をネストすることができます。ネスティングは基本的に、異なるレベルの異なる要素、章、副章、段落のような本のようです。 この構造を保存して、XSDに対して検証したい特定のXML形式にエクスポートできるようにする必要があります。これにより、ドキュメントの構造が検証されます。Word 2010は、多くのコンテンツコントロール(選択肢)で非常に遅くなります。

多くのコンテンツコントロールが必要な大きなドキュメントを処理する必要がある場合を除いて、すべてコンテンツコントロールでうまく動作します。私は2000以上のコンテンツコントロールを話しているので、Word用に扱うのは大変です。その場合、Wordは非常に遅くなります。例えば、Wordの末尾にスペルチェックを実行している間に、ドキュメントの一番下までスクロールするとしばらく時間がかかります。ときどきWordは、そのようなドキュメントを開くこともクラッシュします。

非常に大きな文書でWordの処理速度が遅くなることがあるので、私は既に文書から元に戻す情報を削除しようとしました。その後、ドキュメントサイズは少し縮小しましたが、パフォーマンスの問題は解決されません。これをスピードアップするために何かできることはありますか、この量の必要がある場合(つまり500を超えるコンテンツコントロールなど)、コンテンツコントロールは必要ないだけですか?

コンテンツコントロールがノーウェイのシナリオである場合、ドキュメントの構造を追跡する代替手段はありますか?スタイルを使用しようとしましたが、ドキュメントの個々の要素の入れ子になった情報が失われるので、解析するのがずっと難しくなります。私はまた、すべてのグループ化要素の先頭にブックマークを入れてみましたが、ブックマークの入力中に削除することができます。

アイデア、ヒント、ヒントをお待ちしております。前もって感謝します!

ルーベン。

答えて

0

http://docx.codeplex.com/を使用してみると、MSワードをインストールする必要はありません。

+0

提案してくれてありがとうミカ。つまり、ユーザーはWord 2010を使用してドキュメントを編集します。アドインは、新しい章、サブチャプター、または段落を挿入するために使用できるいくつかのボタン付きのリボンをWordに追加します。問題は、Word文書そのものの生成ではなく、私たちが使用しているコンテンツコントロールの量の制限(よりよく思われる)です。 – Ruben

0

コンテンツコントロールのタグプロパティを使用していない場合は、代わりにマージフィールドを使用していますか?コンテンツコントロールを使用してドキュメントをどのように処理しているかに応じて、パフォーマンスが大幅に向上して同じ機能が提供される可能性があります。マージフィールドはメモリスペースを必要とせず、コンテンツコントロールよりもはるかに簡単に作成されます。

+0

ありがとうございます。それは実際には良い考えです。私はすでにコンテンツコントロールをはるかに少なくして、制限を回避することができました。私は、コンテナ要素のコンテンツコントロールと、テキスト要素の特定のスタイルを持つプレーンなバニラの段落のみを使用してしまいました。これによりコンテンツコントロールの数が大幅に削減され、Wordはもはや問題はありません。 – Ruben

関連する問題