2022/12/26 Update
Microsoft 365 Apps での動作をベースに全体的に記事の構成を改訂しました。
こんにちは、Office 開発 サポート チームです。
前回の投稿で Excel のプロセスを統合することについて記載しましたが、今回はこれに関連し、Office を操作するプログラムを開発するときに、プログラムから操作する Office プロセスを自分のプログラム専用にできるか、という話を記載します。
Office を操作するプログラム開発を行う際、プログラムの処理が行いやすいよう、Office アプリケーションのプロパティを変更したり、画面を非表示にすることがあります。このとき、プログラムから行うプロパティ設定や画面の状態を、ユーザーが開いている他の Office ファイルには反映させたくないといった理由から、「ユーザーが起動する Office とプログラムが起動する Office でプロセスを分けたい」というご相談を頂くことがあります。
実現方法
Excel
COM オートメーションで Office を起動してください。 (CreateObject や new、CoCreateInstance など)
Word / PowerPoint
このような動作を実現する方法はありません。
既定の動作
過去投稿で、Office では起動方法によって、既に起動されたプロセスがある場合には、これを利用して新しいファイルを開く動作となることをご紹介しています。
過去の投稿)
タイトル : Excel 2013 からのウィンドウ管理方法変更について – シングル ドキュメント インターフェイス (SDI)
アドレス : https://officesupportjp.github.io/blog/cl0n10dct000i90vs4c2a3pct/
タイトル : Office のプロセス インスタンス制御について
アドレス : https://officesupportjp.github.io/blog/cl0n10de6001p90vsaa9n6gy8/
対応方法 1
過去投稿でご案内している Excel の /x コマンドライン スイッチや DisableMergeInstance レジストリのように、アプリ起動時に新規プロセスで起動するよう変更できる起動方法も一部用意されています。このような仕組みを用いて、後からユーザーがファイルを開くときに、起動済みのプログラム用のプロセスで開かれることを、ある程度は防ぐことができます。
しかし、このような構成を行っても、例えば以下のような方法で 2 つめの Office ファイルを開くと、既存プロセスで開かれます。
- Offie ファイルをダブル クリックする
- OLE 埋め込みオブジェクトとして埋め込まれた Office ファイルを開く
- 他の Office オートメーションを行うプログラムが Process.Start 等の方法で Office プログラムを起動してファイルを開く
対応方法 2
Excel のみは、COM オートメーションでプロセスを起動すると、以下のどちらのシナリオでも、起動した Excel プロセスが既存プロセスにマージされるのを防ぐことができます。
- 既にプロセスが存在する状態で COM オートメーションでプロセスを起動する
- COM オートメーションでプロセスを起動した後、ユーザーが新たにアプリを起動したりファイルを開く
ただし、プログラムから起動したプロセスの Excel 画面を表示状態にしてユーザー操作可能とする場合、その画面内の操作 ([ファイル] - [開く] など) でファイルを開く場合は、そのプロセス内で開きます。
補足
リモートデスクトップで複数のユーザーが 1 つの端末にログインして Office を利用する場合、ユーザー間でプロセスが統合されることはありません。ただし、これを利用して意図的にログインしていないユーザーで Office を起動するような動作は、Office のサポート外の構成となります (Office のサーバーサイド オートメーションと呼ばれる構成に該当します) 。Office の起動ユーザーは、必ずログインしているユーザーで行う必要があります。
Office のサーバーサイド オートメーションについては、公開情報や本ブログの過去投稿でご案内しています。
タイトル : Office のサーバーサイド オートメーションについて
アドレス : https://support.microsoft.com/ja-jp/kb/257757
タイトル : Office サーバー サイド オートメーションの危険性について
アドレス : https://officesupportjp.github.io/blog/cl0mfb7b7001wnwvshfp01l5u/
図解
文章だけでは分かり辛い点もあるかと思いますので、以下に Excel の動作を例にどのような動作になるか、図を用いて説明します。Microsoft 365 Excel での既定の設定の場合を代表として解説します。Excel 以外のアプリでは動作が異なるため注意してください。
まず、以下に自分のプログラムが初めに Excel プロセスを起動した後、他の方法で Excel を利用する場合の動作を図解します。(ここで初めにプログラムからプロセスを起動するときは、Process.Start のように COM オートメーションではない方法での起動を想定しています。)
図 1. 自プログラム (Process.Start) → 他の方法
一方、<対応方法 2> に記載したように COM オートメーションでプロセスを起動した場合の図です。COM オートメーションで起動したプロセスには、他の操作によりファイルを開いた場合もマージされません。
※ ただし先述の通り、①で起動したプロセス内での操作で開くファイルは①のプロセスで開かれます。([開く] メニューからの操作や、OLE 埋め込みファイルを開く場合など)
図 2. 自プログラム (COM オートメーション) → 他の方法
次に、先にユーザー操作などですでに Excel プロセスを起動しているところに、自プログラムが Excel を起動した場合について図解します。
図 3. 他の方法 → 自プログラム
また、複数のプロセスが存在する場合の動作はさらに複雑です。以下の図に示す通り、既存プロセスに統合される場合にどちらのプロセスに統合されるかは、明確に決められておりません。
図 4. 複数プロセスが存在する場合
以上の通り、Excel では COM オートメーションにより、自プログラムから起動したプロセスを自身専用にすることができますが、Word や PowerPoint では実現できません。また、Excel でも設計によっては、Process.Start 等の起動方法の方が実装しやすい処理もあるかと思いますので、このような場合は、プロセスの専用化とのトレードオフが生じます。
プロセスのマージが生じるようなプログラムを設計する場合は、自ブログラムで起動する Office プロセスがユーザー操作や他のプログラムで起動されるプロセスと統合されても問題ない動作となるよう設計してください。
今回の投稿は以上です。
本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。