JP3181592B2 - 埋め込まれたオブジェクトとイン・プレース対話するための方法及びシステム - Google Patents

Description

【発明の詳細な説明】 発明の分野 本発明は、一般に、リンクされそして埋め込まれたオ
ブジェクトと対話するためのコンピュータ方法及びシス
テムに係り、より詳細には、コンテナーアプリケーショ
ンのコンテクスト内に収容されたオブジェクトを編集
し、さもなくば、それと対話するための方法及びシステ
ムに係る。

先行技術の説明 現在の文書処理コンピュータシステムは、ユーザが複
合文書を作成できるようにする。複合文書とは、種々の
フォーマットの情報を含む文書である。例えば、複合文
書は、テキストフォーマット、チャートフォーマット、
数字フォーマット等のデータを含む。図１は、複合文書
の一例である。この例において、複合文書101は、ある
製造オブジェクトに対するレポートとして形成される。
この複合文書101は、チャートフォーマットで表された
スケジュールデータ102と、スプレッドシートフォーマ
ットで表された予算データ103と、テキストフォーマッ
トで表された説明データ104とを含んでいる。典型的な
公知のシステムでは、ユーザは、プロジェクトマネージ
メントコンピュータプログラムを用いてスケジュールデ
ータ102を発生し、そしてスプレッドシートコンピュー
タプログラムを用いて予算データ103を発生する。この
データが発生された後に、ユーザは、複合文書101を形
成し、説明データ104を入力し、そしてワードプロセス
コンピュータプログラムを使用してスケジュールデータ
102と予算データ103を結合する。

図２は、スケジュールデータ、予算データ及び説明デ
ータを複合文書へいかに組み込むかを示している。ユー
ザは、プロジェクトマネージメントプログラム201を使
用してスケジュールデータを発生し、そしてそのデータ
をクリップボード203に記憶する。ユーザは、スプレッ
ドシートプログラム204を使用して予算データを発生
し、次いで、そのデータをクリップボード203に記憶す
る。クリップボード203は、通常はいかなるプログラム
によってもアクセスできる記憶エリア（ディスク又はメ
モリ）である。プロジェクトマネージメントプログラム
201及びスプレッドシートプログラム204は、通常は、デ
ータをプレゼンテーションフォーマットでクリップボー
ドに記憶する。プリゼンテーションフォーマットとは、
データが出力装置に容易に表示されるフォーマットであ
る。例えば、プレゼンテーションフォーマットは、標準
的なビットマップブロック転送動作（BitBlt）で表示す
ることのできるビットマップである。データをクリップ
ボードに記憶することを、クリップボードに「コピーす
る」と称する。

データがクリップボード203にコピーされた後に、ユ
ーザは、ワード処理プログラム206を始動して複合文書1
01を作成する。ユーザは、説明データ104を入力し、そ
してクリップボード203にあるスケジュールデータ及び
予算データをコピーすべき複合文書101内の位置を指定
する。クリップボードから文書へデータをコピーするこ
とを、クリップボードから「ペーストする」と称する。
次いで、ワードプロセスプログラム206は、スケジュー
ルデータ102及び予算データ103をクリップボード203か
ら複合文書101の指定の位置へコピーする。クリップボ
ードから複合文書へコピーされるデータは、「埋め込ま
れる」データと称する。ワードプロセスプログラム206
は、この埋め込まれるデータを、複合文書101を出力装
置においてレンダリングするときにBitBlt動作で表示す
る単純なビットマップとして処理する。ある公知システ
ムにおいては、クリップボードは、一度に１つのコピー
コマンドに対してデータを記憶することしかできない。
このようなシステムでは、スケジュールデータは、クリ
ップボードにコピーし、そして複合文書へペーストする
ことができる。次いで、予算データをクリップボードに
コピーし、そして複合文書へペーストすることができ
る。

ワードプロセッサは、通常、テキストデータしか処理
しないので、ワードプロセスプログラムのユーザは、埋
め込まれるデータを移動又は削除することはできいる
が、埋め込まれるデータがテキストフォーマットでない
限りそれを変更することはできない。従って、ユーザ
が、例えば、複合文書101内にある予算データ103を変更
したい場合には、ユーザは、スプレッドシートプログラ
ム204をスタートさせ、予算データ103をファイルからロ
ードし、変更を行い、その変更をクリップボード203に
コピーし、ワードプロセスプログラム206をスタートさ
せ、複合文書101をロードし、そして変更されたクリッ
プボードデータを複合文書101へペーストする。スプレ
ッドシートプログラムは、スプレッドシートデータを
「具現化」し、即ちスプレッドシートプログラムを用い
てスプレッドシートフォーマットのデータを操作するこ
とができる。プログラムが具現化するフォーマットを
「ネーティブ」フォーマットと称する。

公知のシステムは、データを実際に埋め込むのではな
く、複合文書に含まれるべきデータに対するリンクを記
憶する。ワードプロセスプログラムがデータをクリップ
ボードから複合文書へペーストするときには、複合文書
にリンクが記憶される。このリンクは、含まれるべきデ
ータ（通常はファイルに存在する）を指すものである。
これらの公知システムは、通常、データに対するリンク
を、ワードプロセスプログラムがプレゼンテーションフ
ォーマットとして確認又は処理するフォーマットで与え
る。例えば、ワードプロセスプログラム206が、ユーザ
により、スケジュールデータ及び予算データを複合文書
へ埋め込みではなくてリンクによってペーストするよう
に指示されるときには、スケジュールデータ及び予算デ
ータがプレゼンテーションフォーマットで存在するファ
イルの名前が文書に挿入される。データの１つのコピー
を多数の複合文書により共用できるようにするために、
多数の複合文書が同じデータに対するリンクを含むこと
ができる。

発明の要旨 本発明の目的は、コンテナー（収容体）オブジェクト
のコンテナーアプリケーションのウインドウ環境内に収
容されたオブジェクトと対話するための方法及びシステ
ムを提供することである。

本発明の別の方法は、コンテナーアプリケーションの
メニューを、収容されたオブジェクトのサーバアプリケ
ーションのメニューと結合するための方法及びシステム
を提供することである。

これら及び他の目的は、本発明の以下の説明から明ら
かとなるように、コンテナーオブジェクト内に収容され
たコンテニー（被収容物）オブジェクトと対話するため
のコンピュータ方法及びシステムにより達成される。好
ましい実施例において、コンテナーオブジェクトは、そ
のコンテナーオブジェクトと対話するためのコンテナー
リソースを有するコンテナーウインドウ環境を伴うコン
テナーアプリケーションを備えている。コンテニーオブ
ジェクトは、そのコンテニーオブジェクトと対話するた
めのサーバリソースをもつサーバウインドウ環境を伴う
サーバアプリケーションを備えている。本発明の方法
は、コンテナーウインドウ環境をディスプレイ装置に表
示する。次いで、ユーザは、コンテニーオブジェクトを
選択する。コンテニーオブジェクトの選択に応答して、
この方法は、複数のサーバリソースを、表示されたコン
テナーウインドウ環境で積分する。ユーザがサーバリソ
ースを選択するときには、この方法は、サーバリソース
選択を処理するためにサーバアプリケーションを呼び出
す。これに対し、ユーザがコンテナーリソースを選択す
るときには、この方法は、コンテナーリソース選択を処
理するためにコンテナーアプリケーションを呼び出す。

図面の簡単な説明 図１は、複合文書の一例を示す図である。

図２は、スケジュールデータ、予算データ及び説明デ
ータを複合文書にいかに組み込むかを示す図である。

図３は、図１に示すサンプル複合文書であって、イン
・プレース対話を行う前にワードプロセスアプリケーシ
ョン内で編集されたときに現れる複合文書を示した図で
ある。

図４は、複合文書内の位置でアクチベーションされた
ときに現れる埋め込まれるスプレッドシートオブジェク
トを示す図である。

図５は、オブジェクトハンドラーとコンテナー及びサ
ーバプロセスとの間の関係を示す図である。

図６は、リンクされるか又は埋め込まれるオブジェク
トのサンプルインスタンスを示すブロック図である。

図７は、オブジェクトのパブリックビューを示すブロ
ック図である。

図８は、オブジェクトに対して使用できるアクション
を表示及び選択するためにコンテナーアプリケーション
により与えられるサンプルユーザメニューを示す図であ
る。

図９は、サーバアプリケーションメニューと図４に示
す例のコンテナーアプリケーションメニューとの合体に
より得られる複合メニューバーを示す図である。

図10は、本発明の好ましい実施例において複合メニュ
ーバーを構成するメニューグループを示す図である。

図11は、典型的なシングル・ドキュメント・インター
フェイスアプリケーションの成分ウインドウを示す図で
ある。

図12は、マルチプル・ドキュメント・インターフェイ
スアプリケーションの成分ウインドウを示す図である。

図13は、埋め込まれたオブジェクトをその位置で編集
するときのコンテナーアプリケーションの典型的なウイ
ンドウハイアラーキ構成を示すブロック図である。

図14は、事象駆動のウインドウオペレーティングシス
テム環境におけるメッセージ処理を示すフローチャート
である。

図14Bは、イン・プレース対話をサポートするのに必
要なパブリックインターフェイスを示すブロック図であ
る。

図15は、IOLEInPlaceFrame::SetMenu方法の具現化を
示すフローチャートである。

図16は、IOLEInPlaceFrame::EnableModeless方法の具
現化を示すフローチャートである。

図17は、IOLEInPlaceParent::OnInPlaceActivate方法
の具現化を示すフローチャートである。

図18は、IOLEInPlaceParent::OnUIActivate方法の具
現化を示すフローチャートである。

図19は、IOLEInPlaceParent::OnUIDeactivate方法の
具現化を示すフローチャートである。

図20は、IOLEInPlaceObject::InPlaceDeactivate方法
の具現化を示すフローチャートである。

図21は、IOLEInPlaceObject::InPlaceUIDeactivate方
法の具現化を示すフローチャートである。

図22は、IOLEInPlaceObject::Activate方法の具現化
を示すフローチャートである。

図23は、ActivateUIファンクションの具現化を示すフ
ローチャートである。

図24は、CreateObjectToolbarsファンクションの具現
化を示すフローチャートである。

図25は、図４に示した例に対応する共用メニューデー
タ構造体のブロック図である。

図26は、ObjectSetMenuファンクションの具現化を示
すフローチャートである。

図27は、Process_Object_Activationファンクション
の具現化を示すフローチャートである。

図28は、APIファンクションObjectLoadをリンクしそ
して埋め込むオブジェクトの具現化を示すフローチャー
トである。

図29は、IOLEObject::DoVerb方法の具現化を示すフロ
ーチャートである。この方法は、コンテニーオブジェク
トと対話する一次方法である。

図30は、アクチベーション及びデアクチベーションメ
ッセージを処理するためにMDI文書ウインドウのウイン
ドウ手順によって呼び出されたファンクションProcess_
Activation_Messageの具現化を示すフローチャートであ
る。

図31は、Process_Mouse_LButtonUpファンクションの
具現化を示すフローチャートである。

好ましい実施例の詳細な説明 目次 1.概要 2.イン・プレース対話の概要 3.イン・プレート対話のウインドウサポート 4.イン・プレート対話API 4.1 IOLEWindowインターフェイス 4.1.1 IOLEWindow::GetWindow 4.2 IOLEInPlaceUIWindowインターフェイス 4.2.1 IOLEInPlaceUIWindow::GetBorder 4.2.2 IOLEInPlaceUIWindow::QueryBorderSpace 4.2.3 IOLEInPlaceUIWindow::SetBorderSpace 4.3 IOLEInPlaceFrameインターフェイス 4.3.1 IOLEInPlaceFrame::SetMenu 4.3.2 IOLEInPlaceFrames::InsertMenus 4.3.3 IOLEInPlaceFrame::RemoveMenus 4.3.4 IOLEInPlaceFrame::SetStatusText 4.3.5 IOLEInPlaceFrame::EnableModeless 4.3.6 IOLEInPlaceFrame::TranslateAccelerator 4.4 IOLEInPlaceParentインターフェイス 4.4.1 IOLEInPlaceParent:CanInPlaceDeactivate 4.4.2 IOLEInPlaceParent::OnInPlaceActivate 4.4.3 IOLEInPlaceParent::OnUIActivate 4.4.4 IOLEInPlaceParent::OnUIDeactivate 4.4.5 IOLEInPlaceParent::OnDeactivate 4.4.6 IOLEInPlaceParent::ShadeBorder 4.4.7 IOLEInPlaceParent::GetWindowContext 4.5 IOLEInPlaceObjectインターフェイス 4.5.1 IOLEInPlacobject::InPlaceDeactivate 4.5.2 IOLEInPlacobject::InPlaceUIDeactivate 4.5.3 IOLEInPlacobject::TranslateAccelerator 4.5.4 IOLEInPlacobject::Activate 4.5.5 IOLEInPlacobject::ResizeBorder 4.5.6 IOLEInPlacobject::EnableModeless 4.5.7 IOLEInPlacobject::SetVisRecr 4.6 その他のサーバアプリケーションファンクシ
ョン 4.6.1 ActivateUI 4.6.2 CreateNewMenu 4.6.3 CreateObjectToolbars 4.6.4 RemoveMenus 4.7 APIヘルパーファンクションをリンクし埋め込
むオブジェクト 4.7.1 SetActiveObjectHwnd 4.7.2 GetActiveObjectHwnd 4.7.3 ObjectCreateSharedMenu 4.7.4 ObjectDestroySharedMenu 4.7.5 ObjectShade 4.7.6 ObjectSetMenu 5.イン・プレース対話APIの使用 5.1 その位置でのアクチベーションの手順 5.1.1 マルチプルドキュメントインターフェイス
アプリケーション内の位置でのアクチベーション 5.2 プルダウンメニューメッセージ取り扱いのユ
ーザ選択 5.3 その位置でのデアクチベーションの手順 5.4 コンテナアプリケーションを閉じる 5.5 モードレスダイアログとの対話 5.6 アクセラレータキーコンビネーションの取り
扱い 1.概要 本発明は、複合文書のコンテクストにおける埋め込ま
れたデータ又はリンクされたデータと対話するための
「イン・プレース対話（in−place interaction）」と
称する一般的な方法を提供する。即ち、埋め込まれるか
又はリンクされたデータと対話するのに使用されるアプ
リケーションは、複合文書を具現化するアプリケーショ
ンのウインドウコンテクスト（メニュー及びウインド
ウ）を介してユーザにアクセスすることができる。この
アクセス性は、「その位置でのアクチベーション（acti
vation in place）」と称する。好ましい実施例におい
て、埋め込まれるか又はリンクされた（収容された）デ
ータがその位置でアクチベートされたときには、その収
容されたデータを具現化するアプリケーションのメニュ
ーが、複合文書を具現化するアプリケーションのメニュ
ーと合体され、複合メニューバーを形成する。複合メニ
ューバーにおけるメニューの順序は、１組のメニューグ
ループによって決定される。各アプリケーションは、そ
のメニューをこれらのメニューグループに分類し、その
メニューグループの順序で複合メニューバーにメニュー
を配置する。次いで、複合メニューバーは、複合文書を
具現化するアプリケーションのメニューバーとしてイン
ストールされ、そしてこのアプリケーションのウインド
ウに送られたフィルタメッセージにメッセージハンロラ
ーがインストールされる。ユーザがメニュー項目を選択
するときには、メッセージハンドラーは、そのメニュー
項目が、収容されたデータを具現化するアプリケーショ
ンのメニューに属するか、又は複合文書を具現化するア
プリケーションのメニューに属するかを判断する。次い
で、メッセージハンドラーは、その選択されたメッセー
ジ項目に対応する入力メッセージを正しいアプリケーシ
ョンに送信する。

本発明は、収容されたデータをその位置でアクチベー
トする１組の抽象クラス（インターフェイス）及びファ
ンクションを定義する。（Ｃ＋＋プログラミング言語に
おいて、抽象クラスとは、そのデータ及び方法の定義は
もつが、これら方法に対する具現化をもたないクラスで
ある。クラスインスタンスデータを操作するのに使用で
きる方法に対する実際のコードを与えるのは、クラスを
具現化するアプリケーションの役目である。）複合文書
を具現化するアプリケーションは、これらインターフェ
イスの幾つかを具現化する役目を果たし、そして収容さ
れたデータを具現化するアプリケーションは、他のもの
を具現化する役目を果たす。

本発明の好ましい実施例において、複合文書を形成す
るアプリケーションプログラムは、別のアプリケーショ
ンにより発生されたリンクされるか又は埋め込まれるデ
ータの操作を制御する。オブジェクト指向の用語におい
ては、このデータをオブジェクトと称する。（参照文献
Budd.T.「オブジェクト指向のプログラミングの紹介（A
n Introduction to Object−Oriented Programming）」
アジソン・ウェスリー・パブリッシング社、1991年は、
オブジェクト指向の概念及び用語を紹介している。）複
合文書にリンクされるか又は埋め込まれるオブジェクト
は、文書内に「収容」される。又、複合文書は「コンテ
ナー」オブジェクトと称し、そして複合文書内に収容さ
れるオブジェクトは「収容」又は「コンテニー」オブジ
ェクトと称する。図１及び２を参照すれば、スケジュー
ルデータ102及び予算データ103はコンテニーオブジェク
トであり、そして複合文書101はコンテナーオブジェク
トである。ユーザは、予算データ103のようなコンテニ
ーオブジェクトをユーザが編集したい旨をワードプロセ
ッサに指示することができる。予算データ103を編集す
べきことをユーザが指示すると、ワードプロセスプログ
ラムは、その予算データを編集するのにどのアプリケー
ションを使用すべきか（例えば、スプレッドシートプロ
グラム）を決定し、そしてそのアプリケーションに着手
（スタートアップ）する。次いで、ユーザは、その着手
されたアプリケーションを用いて予算データを操作する
ことができ、その変更が複合文書に反映される。予算デ
ータが埋め込まれるオブジェクトとして記憶されるかリ
ンクされるオブジェクトとして記憶されるかにかかわり
なく、同じ手順が使用される。

予算データを編集するのに用いられるアプリケーショ
ンがイン・プレース対話をサポートする場合には、それ
がワードプロセスプログラムによって着手されたとき
に、ワードプロセスプログラムのウインドウ環境内でア
クチベートされる。図３及び４は、埋め込まれる予算デ
ータをその位置でアクチベートするプロセスを示してい
る。

図３は、図１に示すサンプル複合文書であって、イン
・プレース対話が行われる前にワードプロセスアプリケ
ーション内で編集されたときに現れる複合文書を示す図
である。コンテナーアプリケーション301のメインウイ
ンドウは、タイトルバー302、メニューバー303及びクラ
イエントウインドウ304を含んでいる。クライエントウ
インドウ304は、図１について述べた製造プロジェクト
レポートを表示する。複合文書は、埋め込まれたスプレ
ッドシートオブジェクト（予算データ305）を含む。ユ
ーザが複合文書のネーティブテキストデータを編集する
ときには、メニューバー303は、図示したように現れ
る。即ち、これは、ワードプロセスアプリケーションと
対話するに必要な全てのコマンドを含む。

ユーザは、予算データ305を編集することを決定する
と、スプレッドシートオブジェクト305を選択し、そし
てオブジェクトを編集するようにワードプロセスアプリ
ケーションに要求する（例えば、マウスを用いたダブル
クリックにより）。ワードプロセスアプリケーション
は、次いで、スプレッドシートアプリケーションに着手
して、スプレッドシートオブジェクト305を編集するよ
う要求する。スプレッドシートアプリケーションは、ワ
ードプロセスアプリケーションのウインドウ301及び304
とメニューバー303とを用いてスプレッドシートオブジ
ェクト305を編集するようにワードプロセスアプリケー
ションと交渉する。

図４は、複合文書内の位置においてアクチベートされ
たときに現れる埋め込まれたスプレッドシートオブジェ
クトを示す図である。スプレッドシートオブジェクト40
5は、ワードプロセスアプリケーションのクライエント
ウインドウ404において直接編集される。タイトルバー4
02は、複合文書を具現化するアプリケーション、この場
合はワードプロセスアプリケーションが、複合文書「VA
C1.DOC」内のスプレッドシートワークシートを編集する
ことを反映するように変更される。又、メニューバー40
3は、ワードプロセスアプリケーションからのメニュー
と、スプレッドシートアプリケーションからのメニュー
とを含む新たな複合メニューバーに変更される。更に、
埋め込まれたスプレッドシートオブジェクト405の種々
の特徴は、それがコンテナー複合文書内で編集されてい
ることを反映するように変更される。陰影付けされた境
界パターンの形態である選択ハイライト406がオブジェ
クトの周りに配置される。又、スプレッドシートアプリ
ケーションの標準ツール、この場合は行列マーク407が
スプレッドシートオブジェクトの周りに配置される。
又、現在選択されたセルの周りにはスプレッドシート選
択カーソル408が配置される。この点において、ユーザ
は、全てのスプレッドシートアプリケーションコマンド
を用いてスプレッドシートオブジェクト405を編集する
準備ができる。

好ましい実施例において、アプリケーションプログラ
ム（アプリケーション）は、オブジェクトをリンクし及
び埋め込む構成体を用いて互いに共働し、複合文書の形
成及び操作を行う。複合文書を形成するアプリケーショ
ンは、コンテナー（又はクライエント）アプリケーショ
ンと称し、そしてコンテニーオブジェクトを形成及び操
作するアプリケーションは、サーバアプリケーションと
称する。アプリケーションは、コンテナー及びサーバの
両方として働くことができる。即ちアプリケーションは
オブジェクトを含むことができ、そしてアプリケーショ
ンが具現化するオブジェクトは他のオブジェクト内に含
むことができる。図２を参照すれば、オブジェクトマネ
ージメントプログラム201及びスプレッドシートプログ
ラム204はサーバアプリケーションであり、そしてワー
ドプロセスプログラム206はコンテナーアプリケーショ
ンである。コンテナーアプリケーションは、コンテナー
オブジェクト内で種々のオブジェクトを選択しそしてコ
ンテニーオブジェクトを操作するための適切なサーバア
プリケーションを呼び出すという役目を果たす。サーバ
アプリケーションは、コンテニーオブジェクトの内容を
操作する役目を果たす。

好ましい実施例において、アプリケーションには、具
現化とは独立したアプリケーションプログラミングイン
ターフェイス（API）が与えられ、これは、オブジェク
トをリンクしそして埋め込む機能を果たすものである。
APIは、コンテナー及びサーバアプリケーションによっ
て呼び出される１組のファンクションである。これらの
ファンクションは、他のものの中でも、コンテナーアプ
リケーションがサーバアプリケーションとの間でメッセ
ージ及びデータをやり取りするのに必要な設定及び初期
化を管理する。

サーバアプリケーションの呼び出しは、サーバアプリ
ケーションがコンテナーアプリケーションとは個別のプ
ロセスとして実行されるときには比較的低速である。あ
る状態においては、この低速さは特に望ましくない。例
えば、ユーザが、多数のコンテニーオブジェクトを含む
複合文書をプリントしようとする場合は、各コンテニー
オブジェクトに対するサーバプロセスを呼び出してオブ
ジェクトをプリントするよう各サーバプロセスに要求す
るのに、受け入れられないほど長い時間がかかる。この
受け入れられない性能を改善するために、サーバアプリ
ケーションは、ランタイム中に、コンテナーアプリケー
ションのプロセスに動的にリンクして更に効率的なある
機能を発揮できるようにするコードを与えることができ
る。このコードは「オブジェクトハンドラー」と称す
る。このオブジェクトハンドラーは、オブジェクトをリ
ンクし埋め込むAPIがサーバプロセスをスタートしてサ
ーバプロセスにメッセージを通すのを回避できるように
サーバアプリケーションに代わる機能を発揮する。上記
の例では、オブジェクトハンドラーは、オブジェクトを
リンクし埋め込むAPIがコンテニーオブジェクトのプリ
ントを呼び出しできるようなプリントファンクションを
与えることができる。

図５は、オブジェクトハンドラーとコンテナー及びサ
ーバプロセスとの間の関係を示す図である。オブジェク
トハンドラー502は、ランタイム中に、オブジェクトリ
ンク及び埋め込みAPI503によってコンテナープロセスア
ドレススペース501にリンクされる。典型的に、オブジ
ェクトリンク及び埋め込みAPI503は、オブジェクトハン
ドラー502を直接呼び出し、そしてコンテナーアプリケ
ーションコードは、ハンドラーがサーバプロセス507以
外の機能を与えることに気付く必要はない。

１組のファンクションを与えるのに加えて、オブジェ
クトリンク及び埋め込み（OLE）APIは、コンテナーアプ
リケーションがそれらの収容されたオブジェクトと通信
できるようにする「インターフェイス」を定義する。イ
ンターフェイスは、ある入力、出力及び振る舞いルール
により遵守する１組の方法（Ｃ＋＋言語での）である。
収容されたオブジェクトが特定のインターフェイスをサ
ポートする場合には、コンテナーアプリケーションは、
そのインターフェイスの方法を呼び出して、定義された
振る舞いを行うことができる。特定の実施例では、コン
テナーアプリケーションは、オブジェクトデータを直接
アクセスしない。むしろ、サポートされたインターフェ
イスを用いてオブジェクトデータをアクセスするのが好
ましい。コンテナーアプリケーションは、インターフェ
イスに対するポインタを介して収容されたオブジェクト
へ結合される。コンテナーアプリケーションは、インタ
ーフェイスの方法を呼び出すことによりオブジェクトデ
ータをアクセスする。オブジェクトデータをアクセスす
るために、これら方法は、指定のアクセスを要求するサ
ーバアプリケーションへメッセージを送信する。好まし
い実施例において、メッセージは、サーバアプリケーシ
ョンがその基礎となるオペレーティングシステムにより
与えられるプロセス間通信メカニズムを用いて個別のプ
ロセスとして具現化されるときにコンテナーアプリケー
ションとサーバアプリケーションとの間に送られる。

図６は、リンクされるか又は埋め込まれたオブジェク
トのサンプルインスタンスを示すブロック図である。好
ましい実施例において、インスタンスのレイアウトは、
参考としてここに取り上げる「オブジェクト指向のプロ
グラミング言語のためのコンパイラーにおいて仮想ファ
ンクション及び仮想ベースを具現化するための方法（A
Method for Implementing Virtual Functions and Virt
ual Bases in a Compiler for an Object Oriented Pro
gramming Language）」と題する米国特許出願第07/682,
537号に規定されたモデルに合致する。このインスタン
スは、各々のサポートされるインターフェイスに対する
オブジェクトデータ構造601及びインターフェイスデー
タ構造61を含んでいる。オブジェクトデータ構造601
は、インターフェイスデータ構造613に対するポインタ6
02を含み、そしてインスタンスのプライベートデータを
含んでもよい。このサンプルインスタンスのプライベー
トデータは、クラス識別子603と、オブジェクトの記憶
に対するハンドル604と、オブジェクトの状態を追跡す
るためのデータ605とを備えている。クラス識別子（CLA
SS_ID）は、オブジェクトに対する適切なサーバアプリ
ケーションをアクセスするのに使用される。これは、プ
ログラミング言語に使用されるデータ構造「タイプ」と
同様である。インターフェイスは、CLASS_IDを永続的な
グローバルな登録簿へのインデックスとして用いること
によりオブジェクトに対するサーバアプリケーションを
決定することができる。永続的なグローバルな登録簿は
以下で詳細に説明する。図６に示すように、各インター
フェイスデータ構造613は、プライベートデータ構造606
及び仮想ファンクションテーブル608を含む。プライベ
ートデータ構造606は、仮想ファンクションテーブル608
に対するポインタ607を含む。仮想ファンクションテー
ブル608は、インターフェイスの方法を具現化するコー
ド610、612に対するポインタ609、611を含む。

テーブル１は、オブジェクトデータ構造601における
第１エントリーpintf₁に対するインターフェイスの定義
を表している。テーブル１において、語「インターフェ
イス」は、Ｃ＋＋クラスを意味するものと定義される。
この定義は、３つの方法をそれらのパラメータと共に示
している。各パラメータリストの端にある「＝０」は、
その方法がコードの具現化をもたないことを意味する。
Ｃ＋＋プログラミング言語において、これらのファンク
ションは「純粋な仮想ファンクション」と称される。純
粋な仮想ファンクションをもつクラスは、抽象クラスと
称される。

図７は、オブジェクトのパブリックビューを示すブロ
ック図である。オブジェクトのパブリックビューは、オ
ブジェクトが702ないし706をサポートする種々のインタ
ーフェイスである。各インターフェイスは、コンテナア
プリケーションがオブジェクトをアクセスできるように
する方法を与える。各オブジェクトは、IUnknownインタ
ーフェイス702をサポートする。コンテナーアプリケー
ションは、IUnknownインターフェイス702を使用して、
オブジェクトが他のインターフェイスのどれをサポート
するかを決定する。特定のオブジェクトに対するIUnkno
wnインターフェイス702の具現化は、オブジェクトが他
のどんなインターフェイスをサポートするかを知り、そ
してそれらインターフェイスに対する呼び出しアプリケ
ーションポインタへ復帰する。好ましい実施例では、方
法IUnknown::QueryInterfaceがこの目的に使用される。
インターフェイス703ないし706は、オブジェクトによっ
てサポートすることのできる典型的なインターフェイス
の例である。これらのインターフェイスは、IUnknownイ
ンターフェイスから導出される。例えば、IDataObject
インターフェイス703は、データを記憶すると共にオブ
ジェクトからデータを検索するための方法を与える。IO
LEContainer704は、オブジェクト内に収容されるコンテ
ニーオブジェクトをリストするための方法を与える。IP
ersistStorageインターフェイス705は、オブジェクトを
永続的な記憶装置に記憶したりそこからオブジェクトを
検索したりする方法を与える。IOLEObjectインターフェ
イス706は、コンテナーアプリケーションがユーザ選択
アクションに対応するオブジェクトの機能を呼び出すと
ころの方法を与える。

APIに加えて、本発明のオブジェクトリンク及び埋め
込み構成体は、永続的なグローバルな「登録簿」により
コンテナー及びサーバアプリケーションへ情報を与え
る。この登録簿は、（１）オブジェクトの各タイプごと
に、オブジェクトタイプを具現化するサーバアプリケー
ション、（２）各サーバアプリケーションがコンテナー
アプリケーションに与えるアクション、（３）各サーバ
アプリケーションに対する実行可能なファイルが置かれ
た場所、及び（４）各サーバアプリケーションがそれに
関連したオブジェクトハンドラーを有するかどうか、と
いった情報のデータベースである。

2.イン・プレース対話の概要 オブジェクトがいったん文書にリンクされるか又は埋
め込まれると、ユーザはオブジェクトを選択しそしてそ
の選択されたオブジェクトに基づいてあるアクションを
実行することを要求する。ユーザは、先ず、オブジェク
トを選択しそしてオブジェクトに基づいて実行されるべ
きアクション（例えば、メニュー項目）を選択すること
によりアクションを要求する。次いで、具現化するサー
バアプリケーションが呼び出され、その選択されたアク
ションを実行する。考えられるアクションの選択をユー
ザに表示しそしてユーザがアクションを選択できるよう
にする方法は多数あることが当業社に明らかであろう。
好ましい実施例では、コンテナーアプリケーションは、
グロバールな登録簿から、その選択されたオブジェクト
を具現化するサーバアプリケーションによってどんなア
クションがサポートされるかを判断し、そしてアクショ
ンをメニューに表示する。

図８は、オブジェクトに対して使用できるアクション
を表示しそして選択するためにコンテナーアプリケーシ
ョンによって与えられる例示的なユーザメニューを示
す。メニュー項目803は、コンテナーアプリケーションE
dit（編集）メニュー802におけるオブジェクトのエント
リーである。このエントリーは、現在選択されたオブジ
ェクトに基づいて変化する。埋め込まれるか又はリンク
されたオブジェクトが選択されないときは、メニュー項
目803は表示されない。サブメニュー804は、「エクセル
・ワークシート・オブジェクト（Excel Worksheet Obje
ct）」によってサポートされるアクションを表示する。
この例では、サポートされるアクションは、「Edit」、
「Open（オープン）」及び「Type（タイプ）」である。
サブメニューを最初のアクション（例えば、「Edit」）
は、ユーザがオブジェクトのマウスポインタ装置でダブ
ルクリックするか又は機能的に等価なキーを入力すると
きに実行されるデフォールトアクションである。

ユーザが所望のアクションを選択すると（メニューか
ら又はオブジェクトにおけるダブルクリック動作によ
り）、コンテナーアプリケーションは、サーバアプリケ
ーションを呼び出し、コンテナーアプリケーションに代
わってどんなアクションを実行すべきかをそこに通す。
コンテナーアプリケーションは、オブジェクトに対する
IOLEObjectインターフェイスを得そしてオブジェクトの
DoVerb方法を呼び出して、選択されたアクションをそこ
に通すことにより、これを行う。（DoVerb方法は、オブ
ジェクトにおいてオブジェクトに特定のアクションを実
行する。）サーバアプリケーションは、次いで、コンテ
ナアプリケーションのコンテクスト内な位置でオブジェ
クトをアクチベートできるかどうかを決定する。もしそ
うならば、サーバアプリケーション及びコンテナアプリ
ケーションは、それらのメニューを複合メニューバーに
合体し、サーバアプリケーションツールバー、パレッ
ト、公式等の配置を交渉し、そして合体されたメッセー
ジの取り扱いを設定する。この点において、サーバアプ
リケーションは、ユーザ入力を受け取る準備ができる。

図４の例を続けると、図示されたように、ユーザは、
ワードプロセスアプリケーションのウインドウ環境内の
位置においてスプレッドシートオブジェクト（予算デー
タ405）を編集する。図９は、サーバアプリケーション
のメニューと、図４に示す例のコンテナーアプリケーシ
ョンメニューとの合体により生じる複合メニューバーを
示す図である。複合メニューバー901は、ワードプロセ
スアプリケーションからのメニュー902、905と、スプレ
ッドシートアプリケーションからのメニュー903、904、
906とを備えている。ユーザがこれらメニューの１つか
ら特定のメニュー項目を選択すると、コンテナーアプリ
ケーションは、合体されたメッセージハンドラーによ
り、メッセージをワードプロセスアプリケーションへ発
送すべきか、スプレッドシートアプリケーションへ発送
すべきかを決定する。

本発明の好ましい実施例では、複合メニューバーは、
１組の所定の規定に基づいて形成される。複合メニュー
バーに含まれるべき各アプリケーションメニューは、メ
ニューグループに指定される。次いで、メニューは、そ
の指定されたメニューグループに基づいて複合メニュー
バーに挿入される。

図10は、本発明の好ましい実施例において複合メニュ
ーバーを構成するメニューグループを示す図である。複
合メニューバー1003は、コンテナーアプリケーションか
らのメニューグループ1001と、サーバアプリケーション
からのメニューグループ1002とを備えている。コンテナ
アプリケーションのメニューグループ1001は、ファイル
グループと、コンテナーグループと、ウインドウグルー
プとを含む。サーバアプリケーションのメニューグルー
プ1002は、編集グループと、オブジェクトグループと、
ヘルプグループとを含む。好ましい実施例において、コ
ンテナー及びサーバアプリケーションのメニューは、参
考としてここに取り上げる1992年マイクロソフト社の
「ザ・ウインドウズ・インターフェイス：アプリケーシ
ョンデザインガイド（The Windows Interface:An Appli
cation Design Guide）」に規定されたマイクロソフト
アプリケーションユーザインターフェイススタイルガイ
ドラインに基づいて最終的な複合メニューバーにインタ
ーリーブされる。特に、複合メニューバー1003におい
て、グループは、次の順序、即ちファイル、編集、コン
テナー、オブジェクト、ウインドウ及びヘルプの順に、
左から右へ配列される。

3.イン・プレース対話のウインドウサポート 好ましい実施例においては、イン・プレース対話API
は、その基礎となるウインドウシステムの能力を用いて
具現代される。本発明は、その基礎となるウインドウシ
ステムがマイクロソフトウインドウズ3.1オペレーティ
ングシステム（“Windows"）に類似したものであると仮
定して説明するが、本発明は、異なる基礎的なウインド
ウシステムでも実施できることが当業者に明らかであろ
う。マイクロソフトウインドウズ3.1オペレーティング
システムは、参考としてここに取り上げる1992年マイク
ロソフト社の「プログラマの参考書、第２巻：ファンク
ション（Programmer's Reference.Volume 2:Function
s）」;1992年マイクロソフト社の「プログラマの参考
書、第３巻：メッセージ、構造及びマクロ（Programme
r's Reference,Volume 3:Messages,Structures,and Mac
ros）」；及び1992年マイクロソフト社の「プログラミ
ングの手引き（Guide to Programming）」に掲載されて
いる。

ウインドウ環境では、アプリケーションは、単一文書
インターフェイス又は多文書インターフェイスをサポー
トする。単一文書インターフェイス（SDI）アプリケー
ションは、一度に１つの文書（ファイル）と対話する。
例えば、SDIをサポートするワードプロセスアプリケー
ションは、現在編集されているファイルをその一次ウイ
ンドウに表示する。多文書インターフェイス（MDI）の
アプリケーションは、各文書に対して少なくとも１つの
ウインドウを割り当てることにより多数の文書（ファイ
ル）と対話する。例えば、MDIをサポートするワードプ
ロセスアプリケーションは、現在編集されている各ファ
イルを個別の文書ウインドウに表示する。ユーザは、所
望の文書ウインドウのタイトルバーにおいてクリックす
るか、又はアプリケーションのウインドウメニュー上の
リストからウインドウタイトルを選択することにより、
ユーザが編集しようとするファイルの文書ウインドウを
選択する。

図11は、典型的な単一文書インターフェイスアプリケ
ーションの成分ウインドウを示す図である。典型的なSD
Iアプリケーションは、フレームウインドウ1101を与
え、そしてアプリケーションによっては、埋め込まれた
オブジェクトの存在に対し区画ウインドウ1105及び1106
と、親ウインドウ1107とを更に与えることができる。SD
Iアプリケーションの場合には、フレームウインドウ110
1は文書ウインドウでもある。区画ウインドウ1105、110
6は、複合文書の多数のビューを与える。親ウインドウ1
107は、オブジェクトが複合文書に最初に挿入されたと
きにオブジェクトの輪郭を描くようにコンテナーアプリ
ケーションによって形成される。図11に示す例では、埋
め込まれたオブジェクトはスプレッドシートオブジェク
トであり、これは、コンテナーアプリケーションの親ウ
インドウ1107内に収容されたオブジェクトウインドウ11
08内に表示される。オブジェクトウインドウ1108は、サ
ーバアプリケーションによって所有される。フレームウ
インドウ1101は、タイトルバー1102と、メニューバー11
03と、ツールバー1104とを含む。典型的に、ツールバー
及びその他のアプリケーションに特定のツールは、フレ
ームウインドウに取り付けられるか、又はコンテナーア
プリケーションの区画ウインドウに取り付けられる。
又、これらは、図11に示すウインドウとは独立したウイ
ンドウであるフローティングパレットとしても現れ、従
って、頂部に「浮動」するように見える。

図12は、典型的な多文書インターフェイスアプリケー
ションの成分ウインドウを示す図である。典型的なMDI
アプリケーションは、ユーザが同じコンテナーアプリケ
ーション内から多数の成分文書を編集できるようにす
る。図12に示す例では、ユーザが、２つの文書ウインド
ウ1205、1206において２つの個別の成分文書を編集す
る。各文書ウインドウは、SDIアプリケーションと同様
に、区画ウインドウを含むことができる。文書ウインド
ウ1205は、２つの区画ウインドウ1207、1208を含む。
又、MDIアプリケーションは、SDIアプリケーションと同
様に、埋め込まれたオブジェクトを収容するための親ウ
インドウ1209を与えることができる。図12は、オブジェ
クトウインドウ1210内に存在する埋め込まれたスプレッ
ドシートオブジェクトを示す。SDIアプリケーションの
場合と同様に、アプリケーションに特定のツールがどこ
かに現れる。

SDI又はMDIのいずれかのアプリケーションにより管理
されるウインドウは、ハイアラーキ形態で形成されそし
て維持される。図13は、埋め込まれたオブジェクトをそ
の位置において編集するときのコンテナーアプリケーシ
ョンの典型的なウインドウハイアラーキを示すブロック
図である。このウインドウハイアラーキは、コンテナー
アプリケーションからのコンテナーアプリケーションウ
インドウ1301と、サーバアプリケーションからのサーバ
アプリケーションウインドウ1307とを備えている。コン
テナーアプリケーション1302は、そのフレームウインド
ウ1303を管理し、該ウインドウは文書ウインドウ1304を
含み、該ウインドウは区画ウインドウ1305を含み、そし
て該ウインドウは親ウインドウ1306を含む。オブジェク
トがその位置においてアクチベートされるときは、サー
バアプリケーション1308は、埋め込まれたオブジェクト
に対するルートウインドウ1309と、これが必要とする子
ウインドウとを形成する。オブジェクトルートウインド
ウ1309は、オブジェクト子ウインドウ1310、1311、1312
を含む。

各アプリケーションは、個別のプロセスとして具現化
されるときに、アプリケーションのウインドウハイアラ
ーキに存在するウインドウに接続された事象を受け取る
ための入力待ち行列を含んでいる。図13のウインドウハ
イアラーキは、２つの異なるアプリケーションによって
サポートされる。従って、コンテナーアプリケーション
に属するウインドウと、サーバアプリケーションに属す
るウインドウとに関連した個別の入力待ち行列がある。
入力待ち行列1313は、コンテナーアプリケーションウイ
ンドウ1301に関連している。入力待ち行列1314は、サー
バアプリケーションウインドウ1307に関連している。ユ
ーザがマウスでクリックするか、又はこれらウインドウ
の１つに対してキーストロークを入力したときに、その
基礎となるウインドウシステムは、コンテナー入力待ち
行列1313又はサーバアプリケーション待ち行列1314のい
ずれかに適当なメッセージを入力する。

4.イン・プレース対話API オブジェクトリンク及び埋め込みAPIは、イン・プレ
ース対話をサポートするためにコンテナーアプリケーシ
ョンとサーバアプリケーションが通信するところのファ
ンクションを与え、そのインターフェイスを定義する。
これらインターフェイスの方法及びその他のAPIファン
クションは、ユーザ入力の通常の処理中にアプリケーシ
ョンコードによって呼び出される。事象駆動されるウイ
ンドウシステムにおいては、アプリケーションは、ユー
ザが特定のメニュー項目又はオブジェクトを選択したこ
とを指示するメッセージを受け取るのに応答して適当な
方法又はファンクションを呼び出す。

図14は、事象駆動式ウインドウオペレーティングシス
テム環境におけるメッセージの処理を示すフローチャー
トである。各ウインドウは、そのウインドウが形成され
るときにその基礎となるウインドウシステムと整列され
るそれ自身のメッセージハンドラーを有している。アプ
リケーション入力待ち行列（例えば、コンテナーアプリ
ケーションの入力待ち行列1313）にメッセージが受け取
られると、アプリケーションは、メッセージをフィルタ
し、変換し、又はウインドウシステムへ発送する。ウイ
ンドウシステムのディスパッチャーは、次いで、メッセ
ージにおいて指示された特定のウインドウに対して既に
整列されているメッセージ取扱ファンクション（メッセ
ージハンドラー）にメッセージを送信する。メッセージ
を受け取ると、メッセージハンドラーは、メッセージを
処理する。この処理は、オブジェクトリンク及び埋め込
みAPIの使用を含む。ステップ1401及び1402は、メッセ
ージポンプを形成する。ステップ1401において、アプリ
ケーションは、その入力待ち行列におけるメッセージを
待機する。ステップ1402において、アプリケーション
は、メッセージを適宜フィルタ又は変換するか、又はメ
ッセージをウインドウシステムのディスパッチファンク
ションへ発送する。ステップ1403及び1404は、ウインド
ウシステムのディスパッチファンクションにおいて、メ
ッセージを適当なウインドウメッセージハンドラーへ発
送するステップである。ステップ1403において、ウイン
ドウシステムディスパッチャーは、メッセージにおいて
指示されたウインドウに対しメッセージハンドラーを位
置決めする。ステップ1404において、ウインドウシステ
ムディスパッチャーは、その位置決めされたメッセージ
ハンドラーへメッセージを送信する（例えば、メッセー
ジハンドラーを呼び出すことにより）。

ステップ1405ないし1412は、ウインドウに対する典型
的なメッセージハンドラーを構成する。メッセージハン
ドラーは、「ウインドウ手順」とも称する。好ましい実
施例において、アプリケーションが特定のウインドウに
対するウインドウ手順を与えない場合には、その基礎と
なるウインドウシステムは、DefWindowProcと称するデ
フォールトウインドウハンドラーを与える。ステップ14
05ないし1408において、アプリケーションは、メッセー
ジをデコードして、どのタイプの事象が生じたかを決定
する。典型的に、各タイプの事象ごとに、アプリケーシ
ョンは、ステップ1409ないし1412に示すように異なるフ
ァンクションを呼び出す。これらのファンクションは、
次いで、オブジェクトリンク及び埋め込みAPIを使用す
る。例えば、メニュー事象が受け取られたときには、ア
プリケーションは、ステップ1411において、メニュー事
象を処理するファンクションを呼び出す。ステップ1411
は、コンテニーオブジェクトをその位置においてアクチ
ベートするProcess_Object_Activationファンクション
（ステップ1413として示す）を呼び出す。以下に詳細に
述べるように、Process_Object_Activationファンクシ
ョンは、オブジェクトリンク及び埋め込みAPIを用い
て、コンテニーオブジェクトをアクチベートする。

イン・プレース対話APIは、次のインターフェイス、
即ちIOLEWindow;IOLEInPlaceUIWindow;IOLEInPlaceFram
e;IOLEInPlaceParent;及びIOLEInPlaceObjectを定義す
る。IOLEWindowインターフェイスは、他のインターフェ
イスの１つに関連したウインドウハンドルを検索するた
めの方法を与えるものである。IOLEInPlaceUIWindowイ
ンターフェイスは、サーバアプリケーションがウインド
ウツールの配置に対してコンテナーアプリケーションと
交渉する方法を与える。IOLEInPlaceFrameインターフェ
イスは、サーバアプリケーションがコンテナーアプリケ
ーションのフレームウインドウと通信する方法を与え
る。IOLEInPlaceParentインターフェイスは、サーバア
プリケーションがコンテナーアプリケーションの親ウイ
ンドウと通信する方法を与える。IOLEInPlaceObjectイ
ンターフェイスは、コンテナーアプリケーションがサー
バアプリケーションをアクチベート及びデアクチベート
する方法を与える。図14Bは、イン・プレース対話をサ
ポートするのに必要なパブリックインターフェイスを示
すブロック図である。コンテナーオブジェクト14B01
は、IOLEWindowインターフェイス14B02、IOLEInPlacePa
rentインターフェイス14B03及びIOLEInPlaceFrameイン
ターフェイス14B04をサポートする。コンテニーオブジ
ェクト14B05は、IOLEInPlaceObjectインターフェイス14
B06をサポートする。これらインターフェイスの各々に
ついて、以下に詳細に説明する。

4.1 IOLEWindowインターフェイス テーブル２は、IOLEWindowインターフェイスをリスト
したものである。オブジェクト指向の用語において、IO
LEWindowインターフェイスは、他のイン・プレース対話
インターフェイスの「基本的クラス」である。従って、
他のインターフェイスは、IOLEWindowインターフェイス
から導出され、そのパブリック方法を継承する。IOLEWi
ndowインターフェイスには、GetWindowと称する１つの
パブリック方法しかない。

GetWindow方法は、これが呼び出されたIOLEInPlaceUI
Window、IOLEInPlaceFrame、IOLEInPlaceParent又はIOL
EInPlaceObjectインターフェイスに対応するウインドウ
ハンドル（独特のウインドウ識別子）を検索する。検索
されたウインドウハンドルは、通常、その基礎となるウ
インドウシステムファンクションを呼び出すときに使用
される。

4.2 IOLEInPlaceUIWindowインターフェイス テーブル３は、IOLEInPlaceUIWindowインターフェイ
スをリストする。IOLEInPlaceUIWindowインターフェイ
スの方法は、コンテナーアプリケーションの文書及び区
画ウインドウ内のツール配置を交渉するためにサーバア
プリケーションによって呼び出される。

4.2.1 IOLEInPlaceUIWindow::GetBorder GetBorder方法は、サーバアプリケーションがそのツ
ール（子ウインドウとして実現される）を配置できるよ
うにする位置を検索する。この方法は、文書インターフ
ェイスが呼び出されるか区画インターフェイスが呼び出
されるかに基づいて、文書又は区画ウインドウのフレー
ム内に配置された四角形を返送する。サーバアプリケー
ションは、この四角形を検索すると、ツールを配置する
のに必要なスペースの巾を決定することができると共
に、QueryBorderSpace方法を用いてこのスペースを要求
することができる。コンテナーアプリケーションによっ
て返送された四角形が拒絶される場合には、サーバアプ
リケーションは、その位置でのアクチベーションを続け
ないように選択することもできるし、或いはそのツール
をアクチベートしないように選択することもできる。

4.2.2 IOLEInPlaceUIWindow::QueryBorderSpace QueryBorderSpace方法は、サーバアプリケーションが
そのツールを配置することのできる区画又は文書ウイン
ドウ内の指定量のスペースを検索する。この方法は、サ
ーバアプリケーションがそのツール配置に必要なGetBor
derへの以前の通話から検索された四角形内の１つのパ
ラメータ、即ち四角形のボーダースペース、を取り出
す。この方法は、文書又は区画ウインドウが要求を受け
入れられるかどうかの指示を返送する。要求を受け入れ
られない場合には、サーバアプリケーションは、異なる
四角形でこの方法を再び呼び出し、その位置でのアクチ
ベーションを続けないように選択し、又はそのツールを
アクチベートしないように選択することができる。

4.2.3 IOLEInPlaceUIWindow::SetBorderSpace SetBorderSpace方法は、それに関連したコンテナアプ
リケーションに、サーバアプリケーションのツールを配
置するために区画ウインドウ又は文書ウインドウに指定
のスペースを実際に割り当てていることを知らせる。こ
の方法は、QueryBorderSpaceへの以前の通話において区
画又は文書ウインドウからスペースが首尾良く要求され
た後に呼び出される。サーバアプリケーションは、それ
が必要とするスペースを割り当てる役目を果たす。この
方法は、サーバアプリケーションがその子ウインドウに
割り当てようとする１つのパラメータ、即ち四角形のス
ペース、を取り出す。指定された四角形は、以前に首尾
良く要求されたものより小さくてもよい。「指定され
た」という用語は、パスしたパラメータを指し、そして
「特定された」という用語は、特定の方法が属するイン
ターフェイス、クラス、ウインドウ又はオブジェクトを
指す。この方法は、特定された区画又は文書ウインドウ
のユーザインターフェイスリソースのいずれかを必要に
応じて移動し又はサイズ決めする。

4.3 IOLEInPlaceFrameインターフェイス テーブル４は、IOLEInPlaceFrameインターフェイスを
リストする。このIOLEInPlaceFrameインターフェイス
は、そのコンテナーアプリケーションのフレームウイン
ドウと通信するためにサーバアプリケーションにより呼
び出される方法を与える。

4.3.1 IOLEInPlaceFrame::SetMenu SetMenu方法は、指定された複合メニューバーをコン
テナーアプリケーションのメニューバーとしてインスト
ールしたり除去したりし、そして複合メニューバーに対
するメッセージハンドラーをインストールする。図15
は、IOLEInPlaceFrame::SetMenu方法の具現化を示すフ
ローチャートである。この方法は、コンテナーアプリケ
ーションがMDIアプリケーションであるかSDIアプリケー
ションであるかに基づいて異なるメカニズムを使用して
複合メニューバーをインストールする。ステップ1501に
おいて、この方法は、指定された複合メニューバーがNU
LLであるかどうかを決定し、もしそうであれば、ステッ
プ1502へ続き、さもなくば、ステップ1503へ続く。ステ
ップ1502では、この方法は、ヘルパーファンクションOb
jectSetMenuDescriptorを呼び出して、複合メニューバ
ーに対するメッセージハンドラーを除去しそして復帰す
る。ステップ1503では、この方法は、コンテナーアプリ
ケーションがSDIアプリケーションであるかどうかを決
定し、もしそうであれば、ステップ1504へ続き、さもな
くば、ステップ1505へ続く。ステップ1504においては、
この方法は、その基礎となるウインドウシステムファン
クションSetMenuを呼び出し、複合メニューバーをコン
テナーアプリケーションフレームウインドウのメニュー
バーとしてインストールし、そしてステップ1507へ続
く。ステップ1505では、この方法は、フレームウインド
ウにメッセージを送り、そのMDIメニュー設定を実行す
るように通知する。ステップ1506では、この方法は、そ
の基礎となるウインドウシステムファンクションDrawMe
nuBarを呼び出してメニューバーを再描写する。ステッ
プ1507では、この方法は、ヘルパーファンクションObje
ctSetMenuDescriptorを呼び出して、複合メニューバー
に対するメッセージハンドラーをインストールする。ス
テップ1508では、この方法は、そのメニューバーを切り
換えるときに必要となる他のプロセスを実行し、次い
で、復帰となる。

4.3.2 IOLEInPlaceFrame::InsertMenus InsertMenus方法は、コンテナアプリケーションのメ
ニューを、サーバアプリケーションによって形成される
複合メニューバーに挿入する。コードテーブル１は、IO
LEInPlaceFrame::InsertMenus方法を具現化するための
擬似コードを示す。この方法は、複合メニューバーと、
メニューカウントのアレーとの２つのパラメータをと
る。コンテナアプリケーションのメニューによって表さ
れたメニューグループの各々に対し、そのグループに対
するメニューを挿入するループがある。ライン１ないし
10において、何らかのファイルグループメニューがある
場合には、この方法は、これらのメニューを複合メニュ
ーバーに挿入し、そしてファイルグループに対応するイ
ンデックスにおいてメニューカウントアレーを増加す
る。（例えば、図４の例に示されたメニューバーが使用
される場合には、インデックス＝０である。）ライン11
ないし20において、何らかのコンテナーグループメニュ
ーが存在する場合には、この方法は、これらのメニュー
を複合メニューバーに挿入し、そしてコンテナーグルー
プに対応するインデックスにおいてメニューカウントア
レーを増加する。最後に、ライン21ないし30において、
追加されるべきウインドウグループメニューがある場合
には、この方法は、これらメニューを複合メニューバー
に挿入し、そしてウインドウグループに対応するインデ
ックスにおいてメニューカウントアレーを増加する。こ
の方法の完了時に、各インデックスにおいてメニューカ
ウントアレーに記憶される値は、その特定のメニューグ
ループに対してコンテナーアプリケーションが挿入した
メニューの数を指示する。この方法は、その基礎となる
ウインドウシステムから標準的なファンクション（Crea
teMenu及びInsertMenu）を呼び出し、コンテナーアプリ
ケーションに対するメニューを形成すると共に、それら
を複合メニューバーに挿入する。

4.3.3 IOLEInPlaceFrame::RemoveMenus RemoveMenus方法は、サーバアプリケーションが複合
メニューバーの割り当てを解除する前に、コンテナーア
プリケーションがそのメニューを複合メニューバーから
除去できるようにする。この方法は、IOLEInPlaceObjec
t::InPlaceDeactive方法から呼び出される。RemoveMenu
s方法は、１つのパラメータ、即ちコンテナーメニュー
が記憶される複合メニューバーのハンドルを取り出す。
複合メニューバーは、この方法が呼び出される前に全て
のサーバメニューをクリアすることが予想される。

4.3.4 IOLEInPlaceFrame::SetStatusText SetStatusText方法は、サーバアプリケーションがコ
ンテナーアプリケーションのフレームウインドウの状態
ウインドウ（もし１つあれば）をセットできるようにす
る。通常は、状態ウインドウは、フレームウインドウの
底部に配置され、現在選択に対応する状態又はヒント情
報を含んでいる。SetStatusText方法は、コンテナーア
プリケーションに特定のもので、コンテナーアプリケー
ションがその状態ウインドウをセットするために通常行
うどんなオペレーションも実行する。この方法は、１つ
のパラメータ、即ち状態ウインドウに挿入するためのテ
キストストリングを取り出す。

4.3.5 IOLEInPlaceFrame::EnableModeless EnableModeless方法は、コンテナーアプリケーション
に対して現在表示されているモードレスダイアログをイ
ネーブル又はディスエイブルするものである。モードレ
スダイアログとは、ユーザによって明確に閉じられるま
で表示される入力ウインドウである。このウインドウが
表示される間に、ユーザは他のウインドウと対話するこ
とができる。一方、モードダイアログは、ユーザが受け
入れられる入力を入れるまで他のウインドウ処理を阻止
する入力ウインドウである。この方法は、モードダイア
ログを表示したいが、それに関連したコンテナーアプリ
ケーションがモードレスダイアログを既に表示している
ときにサーバアプリケーションによって呼び出される。

図16は、IOLEInPlaceFrame::EnableModeless方法を具
現化するフローチャートである。この方法は、コンテナ
ーアプリケーションのモードレスダイアログを隠し、そ
して再び呼び出されたときに、モードレスダイアログを
復帰させる。指定されたフラグfEnableが真である場合
には、その隠されたダイアログが表示され、さもなく
ば、現在表示されているいかなるモードレスダイアログ
も隠される（表示から除去されるが、内部メモリのデー
タ構造は割り当て解除されない）。ステップ1601におい
て、この方法は、FEnableが真であるかどうか決定し、
もしそうならば、ステップ1602へ続くが、さもなくば、
ステップ1603へ続く。ステップ1602において、この方法
は、その基礎となるウインドウシステムファンクション
ShowWindowを呼び出し、既にセーブされたモードレスダ
イアログに関連したウインドウを回復させ、次いで、復
帰する。ステップ1603において、この方法は、現在表示
されている次のモードレスダイアログのウイドウハンド
ルをセーブする。ステップ1604において、この方法は、
その基礎となるウインドウシステムファンクションShow
Windowを呼び出し、モードレスダイアログに関連したウ
インドウを隠す。ステップ1605において、このファンク
ションは、表示されたモードレスダイアログが更にある
かどうかを調べるようにチェックを行い、もしあれば、
このファンクションはステップ1603へ戻るようにループ
し、さもなくば、復帰する。

4.3.6 IOLEInPlaceFrame::TranslateAccelerator TranslateAccelerator方法は、サーバアプリケーショ
ンがそれ自身確認しないキーストロークを受け取るとき
に、アクセラレータキー組合せを処理できるようにす
る。アクセラレータキー組合せは、メニューコマンドに
対するキーボードショートカットであり、これについて
は以下で述べる。TranslateAccelerator方法は、サーバ
アプリケーションメッセージポンプにおいて呼び出され
るファンクションObjectTranslateAcceleratorによって
間接的に呼び出される。コンテナーアプリケーション
は、その通常のアクセラレータ処理を実行し、そしてア
クセラレータが処理されたどうかの指示を返送しなけれ
ばならない。この値は、次いで、ファンクションObject
TranslateAcceleratorによってサーバアプリケーション
へ通される。メッセージはサーバアプリケーションから
コンテナーアプリケーションへ転送されているので、こ
の基礎となるウインドウシステムは、指定されたメッセ
ージに関連した付加的なキー状態又はメッセージ情報を
保持していない。

4.4 IOLEInPlaceParentインターフェイス テーブル５は、IOLEInPlaceParentインターフェイス
をリストしている。このIOLEInPlaceParentインターフ
ェイスは、親ウインドウと通信するためにサーバアプリ
ケーションによって呼び出された方法を与える。又、こ
のウインドウは、オブジェクトに対するイン・プレース
「コンテナーサイト」とも称する。

4.4.1 IOLEInPlaceParent::CanInPlaceActivate CanInPlaceActivate方法は、コンテナアプリケーショ
ンがイン・プレース対話をサポートするかどうかを判断
するためにサーバアプリケーションによって使用され
る。この方法は、選択されたコンテニーオブジェクトに
代わってアクチベーションを受け入れるか又は拒絶する
機会をコンテナアプリケーションに与える。この方法
は、コンテナアプリケーションがイン・プレース対話を
許容するかどうかの指示を返送する。

4.4.2 IOLEInPlaceParent::OnInPlaceActivate OnInPlaceActive方法は、サーバアプリケーションが
（アクチベーション時に）新たな複合メニューバーを形
成する前に必要なオペレーションを実行する機会をコン
テナアプリケーションに与えるようにサーバアプリケー
ションによって呼び出される。図17は、IOLEInPlacePar
ent:OnInPlaceActivate方法の具現化を示すフローチャ
ートである。この具現化において行われるオペレーショ
ンは、コンテニーオブジェクトがアクチベートされたこ
とを指示するフラグをステップ1701においてセットする
ことだけである。この情報は、特定のオブジェクトの親
コンテナーオブジェクトがアクチベート又はデアクチベ
ートするように求められたときに後で使用される。この
フラグは、親コンテナーアプリケーションに、それ自身
のユーザインターフェイスをアクチベート又はデアクチ
ベートするのではなく、その中に収容されたオブジェク
ト（ネスト状オブジェクト）をアクチベート又はデアク
チベートする必要があるかどうかを知らせる。

4.4.3 IOLEInPlaceParent::OnUIActivate OnUIActivate方法は、コンテニーオブジェクトをその
位置においてアクチベートする準備として全てのコンテ
ナーアプリケーションメニュー及びツールを除去する。
図18は、IOLEInPlaceParent::OnUIActivate方法の具現
化を示すフローチャートである。この方法によって行わ
れるステップは、コンテナーオブジェクトがその位置で
アクチベートされたオブジェクトそれ自体であるかどう
かに基づいている。ステップ1801において、この方法
は、コンテナーオブジェクトがその位置においてアクチ
ベートされたかどうかを判断する。もしそうでなけれ
ば、この方法は、ステップ1802へ続き、さもなくば、ス
テップ1803へ続く。ステップ1802において、コンテナー
オブジェクトは最上レベルのコンテナオブジェクトであ
る（その位置でアクチベートされない）ので、この方法
は、その通常の手順を用いて、コンテナーアプリケーシ
ョンメニュー及び余分なツールを除去し、そして復帰す
る。ステップ1803において、コンテナーオブジェクトは
コンテニーオブジェクトでもあるので、この方法は、コ
ンテナーオブジェクトをコンテニーオブジェクトとして
処理する方法をアクセスするためにオブジェクト自身の
IOLEInPlaceObjectを検索する。ステップ1804におい
て、この方法は、コンテナーオブジェクトのアクチベー
ト方法を呼び出してそれ自身をデアクチベートする。ス
テップ1805において、この方法は、全てのコンテナーオ
ブジェクトの文書及び区画ウインドウレベルツールを隠
す。ステップ1806において、この方法は、親コンテナー
オブジェクトのシェードボーダー方法を呼び出して、コ
ンテナーオブジェクトの周りからのイン・プレース対話
ユーザフィードバックを除去し、そして復帰する。コン
テナーオブジェクトのオブジェクトウインドウは、実際
には、後でデアクチベートされる（例えば、コンテニー
オブジェクトがデアクチベートするときに）。

4.4.4 IOLEInPlaceParent::OnUIDeactivate OnUIDeactivate方法は、そのユーザインターフェイス
リソースのデアクチベート動作の終わりにサーバアプリ
ケーションによって呼び出され、その親コンテナーアプ
リケーションがそれ自身のユーザインターフェイスをア
クチベートするか又はその親コンテナーアプリケーショ
ンを呼び出して、その親コンテナーアプリケーションが
そのユーザインターフェイスをアクチベートできるよう
にする。図19は、IOLEInPlaceParent::OnUIDeactivate
方法の具現化を示すフローチャートである。この方法
は、コンデナーオブジェクトがコンテニーオブジェクト
それ自体であるか又は最小レベルのコンテナーオブジェ
クトであるかに基づいて２つの異なる振る舞いを与え
る。前者の場合に、このコンテナーがその位置でアクチ
ベートされる新たなオブジェクトになった場合に、それ
自身のユーザインターフェイスがアクチベートされ、さ
もなくば、コンテナーは、その親コンテナーアプリケー
ションに、そのユーザインターフェイスをアクチベート
するように要求する。後者の場合には、コンテナーアプ
リケーションは、通常の手順を用いてそのユーザインタ
ーフェイスを復帰させる。ステップ1901において、この
方法は、コンテナーアプリケーションがコンネニーオブ
ジェクトをアクチベートしたことを指示するフラグをク
リアする。ステップ1902において、この方法は、特定さ
れたコンテナーオブジェクトがコンテニーオブジェクト
であるかどうかを決定し、もしそうでなければ、ステッ
プ1903へ続き、さもなくば、ステップ1905へ続く。ステ
ップ1903において、この方法は、通常の手順を用いてコ
ンテナーアプリケーションのメニュー及びそのタイトル
バーをセットし、そしてステップ1904へと続いて、入力
フォーカスを所望のウインドウへセットし、復帰する。
入力フォーカスは、特定のウインドウがキーボード入力
を受け取るべきときにその特定のウインドウをセットす
る。ステップ1905において、この方法は、フラグABOUT_
TO_ACTIVATEを検討してコンテナーオブジェクトがアク
チベートされたオブジェクトになりつつあるかを判断
し、もしそうでなければ、ステップ1906へ続き、さもな
くば、ステップ1907へ続く。（ABOUT_TO_ACTIVATEフラ
グは、例えば、以下に詳細に述べるProcess_Mouse_LBut
tonUpファンクションにおいてコンテナーアプリケーシ
ョンがユーザによって選択されたときにセットされ
る。）ステップ1906において、この方法は、コンテナー
オブジェクトのIOLEInPlaceParent::OnUIDeactivate方
法を呼び出して、親コンテナオブジェクトのコンテナー
アプリケーションのユーザインターフェイスをアクチベ
ートし、そして復帰する。ステップ1907において、この
方法は、ファンクションActivateUIを呼び出し、コンテ
ナーアプリケーションのユーザインターフェイスをアク
チベートし、そして復帰する。

4.4.5 IOLEInPlaceParent::OnDeactivate OnDeactivate方法は、サーバアプリケーションによっ
て呼び出され、それに関連したコンテナアプリケーショ
ンに、アクチベートされたコンテニーオブジェクトが完
全にデアクチベートされる前にそのコンテナーオブジェ
クトに関連したフラグをセットするか又はいずれかのリ
ソースを解放する機会を与える。この方法は、コンテニ
ーオブジェクトのIOLEInPlaceCbject::InPlaceDeactiva
te方法から呼び出される。

4.4.6 IOLEInPlaceParent::ShadeBorder ShadeBorder方法は、選択されるか又は選択解除され
ようとしているコンテニーオブジェクトの周りに陰影付
けされたパターンボーダーを描くか又はそれを除去す
る。陰影付けされたパターンボーダーは、コンテニーオ
ブジェクトがその位置でアクチベートされたというユー
ザフィードバックを与えるのに用いられる。この方法
は、ヘルパーオブジェクトリンク及び埋め込みAPIファ
ンクションObjectShadeを呼び出して、適切なシェード
パターンを形成することができる。この方法は、２つの
パラメータ、即ちボーダーを配置しなければならないオ
ブジェクトの周りの四角形と、１組のフラグとを取り出
す。この１組のフラグは、ボーダーをオン（SHADEBORDE
R_ON＝１）にすべきかオフにすべきかを指示すると共
に、ボーダーをアクティブウインドウのタイトルバーに
含まれたテキストと同じカラーで描くべき（SHADEBORDE
R_ACTIVE＝１）か又はディスエイブルされたテキストと
同じカラーで描くべきかを指示する。アクティブウイン
ドウは、入力フォーカスをもつウインドウである。

4.4.7 IOLEInPlaceParent::GetWindowContext GetWindowContext方法は、特定のコンテニーオブジェ
クトに関連した１組のコンテナーアプリケーションイン
ターフェイスを返送する。より詳細には、次のパラメー
タを返送する。

pFrame:これはIOLEInPlaceフレームインターフェイス
に対するポインタである。

pDoc:これはIOLEInPlaceUIWindowインターフェイスに
対するポインタである。

pPane:これはIOLEInPlaceUIWindowインターフェイス
に対するポインタである。

lprectChildPson:これは関連するIOLEInPlaceParent
インスタンスが親ウインドウ内にオブジェクトのオブジ
ェクトウインドウを表示する場所に対するポインタであ
る。

hAccelTable:これはコンテナーアプリケーションのア
クセラレータテーブル（以下に述べる）に対するハンド
ルである。

これらの値は、アクチベーション及びデアクチベーシ
ョンを交渉しそして取り扱うためにサーバアプリケーシ
ョンによって使用される。この方法は、これらインター
フェイスのインスタンスを形成してそれをコンテナーア
プリケーションの当該フレーム、文書、区画及び親ウイ
ンドウと関連させる。

4.5 IOLEInPlaceObjectインターフェイス テーブル６は、IOLEInPlaceObjectインターフェイス
をリストしたものである。IOLEInPlaceObjectインター
フェイス方法は、収容されたオブジェクトをアクチベー
ト及びデアクチベートするためにコンテナーアプリケー
ションによって呼び出される。これら方法の幾つかは、
ネスト状に収容されたオブジェクトを収容ハイアラーキ
によりアクセスする。他の方法は、編集メニューを表示
するコンテニーオブジェクトである現在アクティブなオ
ブジェクトのみをアクセスする。別の具現化は、このイ
ンターフェイスを２つの他のものに分割することであ
り、その１つは、アクティブなオブジェクトのみをアク
セスすることであり、そしてもう１つは、収容ハイアラ
ーキによりコンテニーオブジェクトをアクセスすること
である。

4.5.1 IOLEInPlaceObject::InPlaceDeactivate InPlaceDeactive方法は、コンテナーアプリケーショ
ンによって呼び出され、「undo」オペレーションがコン
テニーオブジェクトをアクセスする必要がもはやなくな
った後であって且つコンテナーアプリケーションが閉じ
る前にコンテニーオブジェクトを完全にデアクチベート
する。この方法は、コンテニーオブジェクトをその位置
でアクチベートすることに関連したリソースの最終的な
割り当て解除を実行する。図20は、IOLEInPlaceObjec
t::InPlaceDeactivate方法を具現化するフローチャート
である。この方法は、先ず、そこに収容された（ネスト
状）オブジェクトをアクチベートしたかどうかを決定
し、もしそうであれば、ネスト状オブジェクトのInPlac
eDeactive方法を呼び出す。さもなくば、オブジェクト
はそれ自身でデアクチベートする。ステップ2001におい
て、この方法は、特定されたオブジェクトがコンテナー
オブジェクトでもありそしてネスト状のコンテニーオブ
ジェクトをアクチベートしているかどうか判断する。も
しそうであれば、この方法は、ステップ2002へ続き、さ
もなくば、ステップ2004へ続く。ステップ2002におい
て、この方法はアクチベートされたコンテニーオブジェ
クト（特定されたオブジェクトのサーバアプリケーショ
ンが既に記憶している）のIOLEInPlaceObjectインター
フェイスを検索し、そしてステップ2003において、その
検索されたインターフェイスのIOLEInPlaceObject::Inp
laceDeactivate方法を呼び出し、そして復帰する。ステ
ップ2004において、この方法は、特定されたオブジェク
トのユーザインターフェイスがまだアクティブであるか
どうかを調べるようにチェックし、もしそうであれば、
ステップ2005へ続き、さもなくば、ステップ2006へ続
く。ステップ2005において、この方法は、指定されたオ
ブジェクトのInPlaceUIDeactivate方法を呼び出してそ
れ自身のユーザインターフェイスをデアクチベートし、
次いで、ステップ2006へ続く。ステップ2006において、
この方法は、サーバアプリケーションファンクションRe
move_Menuを呼び出して、複合メニューバーからサーバ
アプリケーションメニューを除去する。ステップ2007に
おいて、この方法は、特定されたオブジェクトのIOLEIn
PlaceFrame::RemoveMenus方法を呼び出して、親コンテ
ナーアプリケーションがこのメニューを複合メニューバ
ーから除去できるようにする。ステップ2008において、
この方法は、オブジェクトリンク及び埋め込みAPIファ
ンクションObjectDestroySharedMenuを呼び出し、複合
メニューバーの構造を割り当て解除する。このObjectDe
stroySharedMenuファンクションは、ウインドウシステ
ムに特定のもので、複合メニューバーに関連した構造を
割り当て解除するためにその基礎となるウインドウシス
テムファンクションが必要とするものを呼び出す。ステ
ップ2009において、この方法は、その基礎となるウイン
ドウシステムファンクションDestroyMenuを呼び出し、
複合メニューバー構造を割り当て解除すると共に、特定
されたオブジェクトに関連したウインドウを割り当て解
除する。最終的に、ステップ2010において、この方法
は、特定されたオブジェクトのコンテナーオブジェクト
のIOLEInPlaceParent::OnDeactivate方法を呼び出し、
そして復帰となる。

4.5.2 IOLEInPlaceObject::InPlaceUIDeactivate InPlaceUIDeactivate方法は、その位置でアクチベー
トされた特定のオブジェクトに関連した全てのユーザイ
ンターフェイスエレメントを隠す。この方法は、複合文
書内の異なるオブジェクト又はエリアのユーザ選択を処
理するときにコンテナーオブジェクトによって呼び出さ
れるか、又は特定のオブジェクトのユーザインターフェ
イスがまだデアクチベートされていない場合に特定のオ
ブジェクトのInPlaceDeactivateファンクション（図20
参照）から呼び出される。図21は、IOLEInPlaceObjec
t::InPlaceUIDeactivate方法を具現化するフローチャー
トである。この方法は、先ず、特定のオブジェクトがコ
ンテナーオブジェクトであってネスト状オブジェクトを
アクチベートしているかどうかを決定し、もしそうなら
ば、ネスト状オブジェクトのInPlaceUIdeactivateのフ
ァンクションを呼び出す。さもなくば、この方法は、そ
れ自身のユーザインターフェイスを隠し、そのユーザイ
ンターフェイスをデアクチベートしたことをそのコンテ
ナーアプリケーションに知らせる。ステップ2101におい
て、この方法は、ネスト状コンテニーオブジェクトがそ
の位置でアクチベートされたことを指示するフラグが真
であるかどうかを決定し、もしそうであれば、ステップ
2102へ続き、さもなくば、ステップ2104へ続く。ステッ
プ2102において、この方法は、アクチベートされたネス
ト状コンテニーオブジェクトに対するIOLEInPlaceObjec
tインターフェイスを検索し、そしてステップ2103にお
いて、ネスト状コンテニーオブジェクトのInPlaceDeact
ivate方法を呼び出し、そして復帰となる。ステップ210
4において、この方法は、フラグABOUT_TO_ACTIVATEをク
リアし、ユーザが異なるオブジェクトを選択したことを
示す。ステップ2015において、この方法は、特定のオブ
ジェクトのアクチベート方法を呼び出し、偽のパラメー
タを送って、デアクチベートする方法を要求する。この
方法は、親コンテナーアプリケーションのフレームウイ
ンドウに関連した全ての特定のオブジェクトのユーザイ
ンターフェイスエレメントを除去する。ステップ2106に
おいて、この方法は、オブジェクトリンク及び埋め込み
APIファンクションSetActiveObjectHwndを呼び出し、特
定のオブジェクトのIOLEInPlaceObjectインターフェイ
スを、親コンテナーアプリケーション文書ウインドウと
の関連から除去する。これは、コンテナーアプリケーシ
ョンがMDIアプリケーションである場合、及びユーザが
後でこの文書ウインドウを選択する場合に、特定のオブ
ジェクトがその位置でもはや再アクチベートされないこ
とを意味する。ステップ2107において、この方法は、そ
の基礎となるウインドウシステムファンクションを用い
て、親コンテナーアプリケーションの区画又は文書ウイ
ンドウに関連したサーバアプリケーションに属するユー
ザインターフェイスエレメントを隠す。ステップ2108に
おいて、この方法は、特定のオブジェクトのIOLEInPlac
eParent::ShadeBorder方法を呼び出して、デアクチベー
トするオブジェクトの周りから陰影付けされたボーダー
パターンフィードバックを除去する。ステップ2109にお
いて、この方法は、その基礎となるウインドウシステム
ファンクションを呼び出し、特定のオブジェクトに関連
したウインドウを隠す。最後に、ステップ2110におい
て、この方法は、IOLEInPlaceParent::OnUIDeactivate
方法を呼び出し、コンテナーアプリケーションがそれ自
身のユーザインターフェイスをインストールし、そして
復帰する。

4.5.3 IOLEInPlaceObject::TranslateAccelerator TranslateAccelerator方法は、コンテナーアプリケー
ションがアクセラレータキーの組合せを処理する機会を
もつ前にサーバアプリケーションがそれらの組合せを処
理できるようにする。アクセラレータキーの組合せは、
メニューコマンドに対するキーボードショートカットで
あり、以下に詳細に説明する。本発明の好ましい実施例
では、その位置でアクチベートされるオブジェクトは、
規定により、先ずアクセラレータキーの組合せを処理す
る。TranslateAccelerator方法は、そのメッセージポン
プにおいてコンテナーアプリケーションによって呼び出
される（コードテーブル９を参照されたい）。この方法
によって実行される必要のある唯一のオペレーション
は、特定のサーバアプリケーションのアクセラレータテ
ーブルでその基礎となるウインドウシステムファンクシ
ョンTranslateAcceleratorを呼び出すことである。この
ような呼び出しは、コンテニーオブジェクトが個別の実
行可能なプロセスによって具現化される場合には必要と
されない。というのは、個別のプロセスは、これらキー
の組合せをそれ自身のメッセージポンプにおいて受け取
るが、コンテナーアプリケーションはそれらを決して受
け取らないからである。この場合に、TranslateAcceler
ator方法は何も行わない。

4.5.4 IOLEInPlaceObject::Activate Activate方法は、指定されたフラグfActiveが真であ
るか偽であるかに基づいて、親コンテナアプリケーショ
ンのフレームウインドウにインストールされたユーザイ
ンターフェイスエレメントをアクチベート又はデアクチ
ベートする。MDI文書ウインドウがアクチベート又はデ
アクチベートされたときに呼び出された場合には、この
方法は、その位置でアクチベートされたオブジェクトに
関連した複合メニューバーをインストールするか又は除
去し、そして特定のオブジェクトがアクチベートされた
場合にはその周りに陰影付けされたボーダーパターンを
配する。最上レベルのフレームウインドウがアクチベー
ト又はデアクチベートされたときに呼び出された場合に
は、この方法は、特定のオブジェクトがアクチベートさ
れた場合にその周りに陰影付けされたボーダーパターン
を配し、さもなくば、それを除去する。この場合に、他
のユーザインターフェイスエレメントをアクチベート又
はデアクチベートする必要はない。図22は、IOLEInPlac
eObject::Activate方法の具現化を示すフローチャート
である。ステップ2201において、この方法は、最小レベ
ルフレームウインドウのアクチベート又はデアクチベー
ト動作の結果として呼び出されたか、或いはMID（子）
文書ウインドウのアクチベート又はデアクチベート動作
の結果として呼び出されたかを決定する。MID文書ウイ
ンドウのアクチベート又はデアクチベート動作の結果と
して呼び出された場合には、この方法は、ステップ2202
へ進み、さもなくば、ステップ2210へ続く。ステップ22
02において、この方法は、特定のオブジェクトをアクチ
ベートすべきかどうかを決定し、もしそうでなければ、
ステップ2203へ続き、さもなくば、ステップ2206へ続
く。ステップ2203において、この方法は、親コンテナー
オブジェクトのIOLEInPlaceFrame::SetMenu方法を呼び
出し、その位置での特定のオブジェクトのアクチベーシ
ョンに関連した複合メニューバーを除去する。ステップ
2204において、この方法は、親コンテナーのアプリケー
ションフレームウインドウにインストールされたユーザ
インターフェイスエレメントを隠す。ステップ2205で
は、この方法は、親コンテナーオブジェクトのIOLEInPl
aceParent::ShadeBorder方法を呼び出し、特定のオブジ
ェクトの周りから陰影付けされたボーダーパターンを除
去し、復帰となる。ステップ2206において、この方法
は、親コンテナーオブジェクトのIOLEInPlaceFrame::Se
tMenu方法を呼び出し、複合メニューバーを関連フレー
ムウインドウのメニューバーとしてインストールする。
ステップ2207において、この方法は、コンテナーアプリ
ケーションのフレームウインドウのタイトルバーをセッ
トして、コンテナーアプリケーションが特定のオブジェ
クトをアクチベートしたことを指示する。ステップ2208
において、この方法は、その基礎となるウインドウシス
テムファンクションを呼び出し、フレームレベルのユー
ザインターフェイスエレメントを表示する。ステップ22
09において、この方法は、親コンテナーオブジェクトの
IOLEInPlaceParent::ShadeBorder方法を呼び出し、特定
のオブジェクトの周りに陰影付けされたボーダーパター
ンを描いて、その位置でアクチベートされたことを指示
し、次いで、復帰となる。ステップ2210において、この
方法は、特定のオブジェクトをアクチベートすべきであ
るかどうかを決定し、もしそうであれば、ステップ2209
へ続き、さもなくば、ステップ2211へ続く。ステップ22
11において、この方法は、特定のオブジェクトの周りか
ら陰影付けされたボーダーパターンを除去し、復帰とな
る。

4.5.5 IOLEInPlaceObject::ResizeBorder ResizeBorder方法は、コンテナーアプリケーションに
よって呼び出され、サーバアプリケーションが親コンテ
ナアプリケーションの区画又は文書ウインドウ内に配置
したユーザインターフェイスツールをサイズ変更するよ
うにサーバアプリケーションに要求する。この方法が呼
び出されるのに応答して、サーバアプリケーションは、
区画又は文書ウインドウに関連したインターフェイスイ
ンスタンスのQueryBorderSpace及びSetBorderSpace方法
を用いてコンテナーアプリケーションとの別のツール配
置交渉ループを開始しなければならない。

4.5.6 IOLEInPlaceObject::EnableModeless EnableModeless方法は、サーバアプリケーションに対
して現在表示されているモードレスダイアログをイネー
ブル又はディスエイブルする。典型的に、この方法は、
図16を参照して上記したIOLEInPlaceFrame::EnableMode
lessと同様に具現化される。

4.5.7 IOLEInPlaceObject::SetVistRect SetVistRect方法は、最も内側のレベルのコンテナー
オブジェクトによって呼び出され、実際に目に見えるオ
ブジェクトの量を通信する。オブジェクトの目に見える
（切り取り）四角形は、例えば、ボーダーの交渉、スク
ロール又はサイジングによって変更されてもよい。指定
された四角形は、切り取り四角形であり、コンテニーオ
ブジェクトのウインドウを正しい（切り取った）目に見
えるサイズにサイズ変更するのはサーバアプリケーショ
ンの役目である。

4.6 その他のサーバアプリケーションファンクショ
ン 好ましい実施例において、サーバアプリケーション
は、次の１組のファンクションを与える。即ち、Activa
teUI;CreateNewMenu;CreateObjectToolBars;及びRemove
Menus。

4.6.1 ActivateUI SCODE ActivateUI（IOLEInPlaceUIW
indow＊pDoc,IOLEInPlaceObject pObject） ActivateUIファンクションは、指定されたコンテニー
オブジェクトのユーザインターフェイスリソースのアク
チベーションを制御するためにサーバアプリケーション
によって具現化されるファンクションである。この高レ
ベルファンクションは、フレーム、文書及び区画レベル
のユーザインターフェイスエレメントをアクチベート
し、オブジェクトの周りに陰影付けされたボーダーパタ
ーンを描き、そして複合メニューバーを表示する。図23
は、ActivateUIファンクションを具現化するフローチャ
ートである。このファンクションは、２つのパラメー
タ、即ち文書インターフェイスに対するポインタと、コ
ンテニーオブジェクトに対するポインタとを取り出す。
ステップ2301において、このファンクションは、指定さ
れた文書ウインドウ及び指定されたコンテニーオブジェ
クトに対するウインドウハンドルを得る。ステップ2302
において、このファンクションは、オブジェクトリンク
及び埋め込みAPIファンクションSetActiveObjectHwndを
呼び出し、指定された文書ウインドウの現在アクティブ
オブジェクトを、コンテニーオブジェクトのインターフ
ェイスに対するポインタにセットする。これは、文書ウ
インドウの１つがユーザにより選択されたときに、MDI
アプリケーションとして具現化されるコンテナーアプリ
ケーションが適切なコンテニーオブジェクトをアクチベ
ートできるようにする。ステップ2303では、このファン
クションは、IOLEInPlaceObject::Activate方法を呼び
出し、指定されたオブジェクトをアクチベートする。ス
テップ2304では、このファンクションは、その基礎とな
るウインドウシステムファンクションShowWindowを呼び
出し、コンテナアプリケーションの区画又は文書ウイン
ドウに関連したユーザインターフェイスエレメントを表
示する。ステップ2305において、このファンクション
は、指定されたコンテニーオブジェクトを取り巻くため
のボーダー又は四角形の寸法を決定し、そしてステップ
2306において、このファンクションは、指定されたコン
テニーオブジェクトのIOLEInPlaceObject::ShadeBorder
方法を呼び出し、この四角形を用いて指定されたコンテ
ニーオブジェクトの周りに陰影付けされたボーダーパタ
ーンを描く。ステップ2307において、このファンクショ
ンは、入力フォーカスを、指定されたコンテニーオブジ
ェクトのオブジェクトウインドウにセットする。最終的
に、ステップ2308において、このファンクションは、そ
の基礎となるウインドウシステムファンクションDrawMe
nuBarを呼び出して、複合メニューバーを再表示し、そ
して復帰となる。

4.6.2 CreateNewMenu HANDLE CreateNewMenu（IOL
EInPlaceFrame＊pFrame） CreateNewMenuファンクションは、複合メニューバー
の形成を管理するためにサーバアプリケーションによっ
て具現化されるファンクションである。このファンクシ
ョンは、複合メニューバーに関連した構造を割り当て、
そのメニューを挿入するようにコンテナーアプリケーシ
ョンを要求し、そしてサーバアプリケーションメニュー
を挿入する。コードテーブル２は、CreateNewMenuファ
ンクションの具現化を表している。ライン１において、
このファンクションは、その基礎となるウインドウシス
テムファンクションを呼び出し、複合メニューバーに対
するデータ構造を形成する。ライン２において、このフ
ァンクションは、コンテナーアプリケーションのフレー
ムウインドウのIOLEInPlaceFrame::InsertMenusを呼び
出し、コンテナアプリケーションのメニューを複合メニ
ューバーに挿入する。ライン３ないし５において、この
ファンションは、各メニューグループに対してコンテナ
ーアプリケーションが挿入したメニューの数を追跡す
る。ライン６ないし17において、サーバアプリケーショ
ンがEditグループメニューを有すると仮定すれば、この
ファンクションは、このファンクションは、各Editグル
ープメニューを形成し、そしてそれを複合メニューバー
における正しいスポットに挿入し、いかに多くのメニュ
ーが挿入されたかを追跡する。正しいスポットは、ライ
ン９において、いかに多くのメニューが既に左側へ挿入
されたかを決定することにより計算される。これは、Ed
itグループに対し、コンテナーアプリケーションがコン
テナーグループの一部として挿入したメニューの数と、
既に挿入されているEditグループのメニューの数と、現
在挿入に対する１との和となる。ライン18ないし30、31
ないし41において、このファンクションは、各々Object
グループ及びHelpグループに属するメニューに対して同
様のステップを実行する。ライン42において、このファ
ンクションは、オブジェクトリンク及び埋め込みAPIフ
ァンクションObjectCreateSharedMenuを呼び出して、複
合メニューバーに対するメッセージハンドリングに関連
したデータ構造を形成し、そしてライン43において、ハ
ンドルをこの構造に返送する。

4.6.3 CreateObjectToolbars void CreateObjectT
oolbars（IOLEInPlaceframe＊pFrame,IOLEInPlaceUIWin
dow＊pDoc,IOLEInPlaceUIWindow＊pPane） CreateObjectToolbarsファンクションは、サーバアプ
リケーションツールに必要なスペースに対しサーバアプ
リケーションとコンテナーアプリケーションとの間で交
渉するためにサーバアプリケーションによって具現化さ
れるファンクションである。図24は、CreateObjectTool
barsファンクションを具現化するフローチャートであ
る。ステップ2401ないし2408は、サーバアプリケーショ
ンに対するツールを形成するように必要に応じて何回も
繰り返される。ステップ2401において、このファンクシ
ョンは、形成すべきツールバーが更にあるかどうかを決
定し、もしなければ、復帰し、さもなくば、ステップ24
02に続く。ステップ2402において、このファンクション
は、（サーバアプリケーションがツールをどこに配置し
たいかに基づいて）コンテナーアプリケーションのフレ
ーム、文書又は区画ウインドウのIOLEInPlaceUIWindo
w::GetBorder方法を呼び出し、交渉を開始する。ステッ
プ2403において、このファンクションは、所望のフレー
ム、文書又は区画ウインドウのIOLEInPlaceUIWindow::Q
ueryBorderSpace方法を呼び出し、GetBorder方法に対す
る以前の呼び出しにより返送された四角形の内側にボー
ダースペースの特定の巾を要求する。これらの方法は、
以下に詳細に説明する。ステップ2404において、特定の
巾を受け入れられない場合には、このファンクションは
ステップ2405に続き、さもなくば、復帰となる。異なる
値で必要な回数だけQueryBorderSpaceを呼び出すことに
より異なる量のスペースに対して交渉するように具現化
を選択することができる。ステップ2405において、この
ファンクションは、ステップ2403で既に交渉されている
スペースでIOLEInPlaceUIWindow::SetBorderSpace方法
を呼び出す。ステップ2406において、このファンクショ
ンは、親コンテナーアプリケーションの所望のフレー
ム、文書又は区画ウインドウの子ウインドウを形成す
る。ステップ2407において、このファンクションは、既
に形成した子ウインドウにツールを描き、次いで、ルー
プの始めに復帰する。

4.6.4 RemoveMenus void RemoveMenus（HANDLE hS
haredMenu） RemoveMenusファンクションは、コンテニーオブジェ
クトのデアクチベーション時に複合メニューバーからサ
ーバアプリケーションのメニューを除去する。この方法
は、コンテニーオブジェクトのInPlaceDeactivate方法
から呼び出される。コードテーブル３は、RemoveMenus
ファンクションの具現化を示す。このファンクション
は、各メニューグループ内に多数のメニューを含む共用
メニュー記述子（図25参照）に記憶された情報を用い
て、その基礎となるウインドウシステムファンクション
RemoveMenuを呼び出すことにより全てのサーバアプリケ
ーションメニューを除去する。ライン３ないし５は、Ed
itグループに属するメニューを除去し、ライン６ないし
８は、Objectグループに属するメニューを除去し、そし
てライン９ないし11は、Helpグループに属するメニュー
を除去する。

4.7 オブジェクトリンク及び埋め込みAPIのヘルパー
ファンクション インターフェイス定義に加えて、オブジェクトリンク
及び埋め込みAPIは、コンテナー及びサーバアプリケー
ションによって使用されるべき１組のヘルパーファンク
ションを与える。これらのファンクションは、SetActiv
eObjectHwnd;GetActiveObjectHwnd;ObjectCreateShared
Menu;ObjectDestroySharedMenu;ObjectShade;及びObjeo
tSetMenuを含む。

4.7.1 SetActiveObjectHwnd void SetActiveObjec
tHwnd（HWND hwndDOC,IOLEInPlaceObject＊pObject） SetActiveObjectHwndファンクションは、MDIアプリケ
ーションの現在選択されたオブジェクトをセットする。
MDIコンテナーアプリケーションの各MDI（文書）ウイン
ドウには、そのMDIウインドウが最後に入力フォーカス
を有したときに表示されたその位置でアクチベートされ
たオブジェクトに対応するオブジェクトインターフェイ
スが関連される。MDIウインドウ内からオブジェクトが
その位置でアクチベートされていない場合には、それに
関連したオブジェクトインターフェイスはNULLである。
このメカニズムは、MDIウインドウが後で入力フォーカ
スを受け取るときに、例えば、ユーザがMDIウインドウ
のタイトルバーにおいてマウスでクリックするときに、
適切なコンテニーオブジェクトをアクチベートするよう
にMDIウインドウをイネーブルする。（ユーザが他のMDI
ウインドウのタイトルバーにおいてクリックするとき
は、第１のウインドウに関連したいかなるイン・プレー
ス対話も表示から消失する。）SetActiveObjectHwndフ
ァンクションは、２つのパラメータ、即ちMDI（文書）
ウインドウのウインドウハンドルと、その位置で現在ア
クチベートされているオブジェクトのIOLEInPlaceObjec
tインターフェイスとを取り上げる。ウインドウハンド
ルをオブジェクトインターフェイスに関連させる方法は
多数あることが当業者に明らかであろう。１つの実施例
において、このファンクションは、オブジェクトインタ
ーフェイスを、その基礎となるウインドウシステムファ
ンクションを用いて文書ウインドウの特性として記憶す
る。この具現化は、システムにおいてアクティブな各MD
Iウインドウごとに記憶装置を必要とすることに注意さ
れたい。別の解決策は、現在選択されるオブジェクトを
追跡する方法を文書、区画及びフレームウインドウイン
ターフェイスに追加する。

4.7.2 GetActiveObjectHwnd HWND GetActiveObjec
tHwnd（HWND hwndDOC） GetActiveObjectHwndファンクションは、MDIウインド
ウが入力フォーカスを受け取るときにその位置でアクチ
ベートされるべきコンテニーオブジェクトを検索する。
このファンクションは、SetActiveObjectHwndファンク
ションを用いて既に記憶されているオブジェクトインタ
ーフェイスを返送する。

4.7.3 ObjeCtcreateSharedMenu HANDLE ObjectCre
ateSharedMenu（HMENU hMenuCombined.UINT lpiMenuCou
nts） ObjectCreateSharedMenuファンクションは、その位置
でアクチベートされたオブジェクトの複合メニューバー
に関連した共用メニューデータ構造を形成する。このフ
ァンクションは、コンテニーオブジェクトがアクチベー
トされたときにCreateNewMenuファンクションから呼び
出される。コードテーブル４は、ObjectCreateSharedMe
nuファンクションの具現化を示す。このファンクション
は、２つのパラメータ、即ち複合メニューバーに対する
ハンドルと、各メニューグループにおけるメニューの数
を含むメニューカウントのアレーとを取り上げる。この
ファンクションは、新たに形成された共用メニューデー
タ構造に対するハンドルを返送する。ライン１におい
て、このファンクションは、共用メニューデータ構造に
必要なメモリを割り当てる。ライン２において、このフ
ァンクションは、このデータ構造における複合メニュー
バーに対するハンドルをセーブする。ライン３ないし15
では、このファンクションは、メニューカウントアレー
に記憶されたファンクションに基づいて共用メニュー記
述子を設定する。この記述子は、メニューコマンドを受
け取るときにウインドウ手順によって使用され、メニュ
ーコマンドをコンテナーアプリケーションに送るべきか
サーバアプリケーションに送るべきかを決定する。

この情報を維持する種々の方法があることが当業者に
明らかであろうが、１つの実施例では、記述子は、各イ
ンデックスにおいて、そのインデックスに関連したメニ
ューグループに含まれた最後のメニューの数を記憶す
る。（メニューは、左側において１から番号付けされ
る。）又、メニューグループがコンテナーアプリケーシ
ョンに属するかサーバアプリケーションに属するかの指
示も各インデックスに記憶される。又、どのメニューグ
ループに対してどのアプリケーションに通知すべきかを
指示する付加的なパラメータを通すことにより、メニュ
ーグループ分け機構もサポートできることが当業者に明
らかであろう。この記述子構成を用いて、ウインドウ手
順は、メニュー項目選択を含むまでメニューの数をカウ
ントしそしてそのメニュー数を記述子の値と比較して正
しいインデックスを見つけることにより、特定のメニュ
ー項目選択がどのインデックス内に入るかを決定するこ
とができる。いったんインデックスが決定されると、ウ
インドウ手順は、コンテナーアプリケーションファンク
ションを呼び出すべきか又はサーバアプリケーションフ
ァンクションを呼び出すべきかを指定する指示子を検索
することができる。この手順は、コードテーブル５を参
照して以下に詳細に述べる。

図25は、図４について述べた例に対応する共用メニュ
ーデータ構造のブロック図である。この共用メニューデ
ータ構造は、複合メニューバーのポインタ2502と、各メ
ニューグループに対するメニューカウントを含む記述子
2505とで構成される。複合メニューバー2503は、コンテ
ナー及びサーバアプリケーション2504からのメニューを
含む。記述子2505の各エレメントは、カウントフィール
ド2506及びファンクションフィールド2507を有する。カ
ウントフィールド2506は、メニューグループ内の最後の
メニューの数（左からスタートして）を指示する。例え
ば、第２のメニューグループは、Editグループであり、
１つのメニューしか含まない。このメニュー2503は、複
合メニューバーにおいて左から２番目のメニューであ
り、それ故、カウントフィールド2509は、数２を含む。
別の例として、４番目のメニューグループは、Objectグ
ループである。このグループは、サーバアプリケーショ
ン2510からの５つのメニューを含む。それ故、このメニ
ューグループ2511のカウントは数７を含む。というの
は、７番目のメニューが、Objectグループにおける最後
のメニューであるMacroメニューだからである。

4.7.4 ObjectDestroySharedMenu void ObjectDest
roySharedMenu（HMENU hMenuCombined） ObjectDestroySharedMenuファンクションは、ObjectC
reateSharedMenuへの以前の呼び出しにおいて形成され
た共用メニューデータ構造を破壊する。このファンクシ
ョンは、コンテナー及びサーバアプリケーションがそれ
らのメニューを複合メニューバーから除去した後に、ア
クチベートされたコンテニーオブジェクトのIOLEInPlac
eObject::InPlaceDeactivate方法から呼び出される。

4.7.5 ObjectShade void ObjectShade（HWND hwnd
Parent,LPRECT 1prc.DWORD grfState） ObjectShadeファンクションは、オブジェクトリンク
及び埋め込みAPIによって与えられ、その位置でアクチ
ベートされたオブジェクトの周りに配置される陰影付け
されたボーダーパターンを形成する。hwndParentパラメ
ータは、アクチベートされた（又はアクチベートされる
べき）オブジェクトのIOLEInPlaceParentインターフェ
イスに関連したウインドウハンドルである。lprcパラメ
ータは、パターンが配置されるところの親ウインドウ座
標における四角形である。grfStateフラグは、IOLEInPl
aceParent::ShadeBorder方法について述べたものと同じ
であり、SHADEBORDER_ON及びSHADEBORDER_ACTIVEを含
む。

4.7.6 ObjectSetMenuDescriptor SCODE ObjectSet
Menu（HWND hwndFrame,HOLEMENU hMenuCombind,HWND hw
ndObject） ObjectSetMenuDescriptorファンクションは、複合メ
ニューバーに対するメッセージハンドラーを設定又は除
去する。このファンクションは、アクチベートするコン
テニーオブジェクトの関連コンテナーオブジェクトのIO
LEInPlaceFrame::SetMenu方法によって呼び出される。
図26は、ObjectSetMenuDescriptorファンクションの具
現化を示すフローチャートである。これは、３つのパラ
メータ、即ちコンテナーアプリケーションに関連したフ
レームウインドウのウインドウハンドル;ObjectCreateS
haredMenuファンクションによって返送された共用メニ
ューデータ構造に対するハンドル；及び現在その位置で
アクチベートされるべきオブジェクトのウインドウハン
ドルを取り上げる。共用メニュー構造に対するハンドル
がナルである場合には、このファンクションは、複合メ
ニューバーに対するメッセージハンドラーを除去し、さ
もなくば、メッセージハンドラーを設定する。ステップ
2601において、このファンクションは、指定された共用
メニューデータ構造に対するハンドルがナルであるかど
うか決定し、もしそうであれば、ステップ2602へ続き、
さもなくば、ステップ2603へ続く。ステップ2602におい
て、このファンクションは、その基礎となるウインドウ
システムファンクションSetWindowLongを呼び出し、コ
ンテナーアプリケーションに既に関連されている特殊な
メッセージハンドラーを除去する。ステップ2603におい
て、このファンクションは、複合メニューに対して既に
設定されている特性を除去し、次で、復帰する。ステッ
プ2604において、このファンクションは、特殊なメッセ
ージハンドラーによっ後で使用されるべき共用メニュー
データ構造を記憶するための特性をフレームウインドウ
にセットする。ステップ2605において、このファンクシ
ョンは、アクチベートするオブジェクトのウインドウハ
ンドルに対応する別の特性をフレームウインドウにセッ
トする。ステップ2606において、このファンクション
は、その基礎となるウインドウシステムファンクション
SetWindowLongを用いて、親コンテナーアプリケーショ
ンのフレームウインドウに対する新たなウインドウ手順
として特殊なメッセージハンドラーをインストールす
る。古いウインドウ手順は、特性Old_Filterに後で使用
するためにセーブされる。（例えば、以下に詳細に述べ
るコードテーブル５を参照されたい。）次いで、ファン
クションは復帰となる。

5.イン・プレース対話APIの使用 イン・プレース対話をサポートするオブジェクトリン
ク及び埋め込みAPIファンクションは、次のことを行う
ために呼び出される。

・SDI又はMDIコンテナーアプリケーション内の場所で
オブジェクトをアクチベートする。

・ユーザがコンテナーアプリケーションの複合メニュ
ーバーからメニュー項目を選択するときにメッセージを
処理する。

・ユーザが異なるオブジェクトをアクチベートするよ
うに選択するか又は最上レベルのコンテナアプリケーシ
ョンをその通常処理に回復するよう選択するときにその
位置でアクチベートされたオブジェクトのユーザインタ
ーフェイスリソースをデアクチベートする。

・コンテナーアプリケーションがイン・プレース対話
リソースをもはや必要としないときにサーバアプリケー
ションに対してそれらリソースをデアクチベートする。

・サーバアプリケーションがダイアログを表示しそし
てコンテナーアプリケーションがモードレスダイアログ
を現在表示する（又はその逆である）ときにモードレス
ダイアログをイネーブル及びディスエイブルする。

・アクセラレータキー組合せをコンテナーアプリケー
ションとサーバアプリケーションとの間に分配するよう
にこれら組合せを処理する。

5.1 その位置でアクチベーションする手順 上記したように、オブジェクトが文書にリンクされる
か又は埋め込まれると、ユーザは、オブジェクトを選択
し、そしてその選択されたオブジェクトに基づいてある
アクションを実行するよう要求する。図３及び４の例に
戻ると、ユーザがスプレッドシートオブジェクト305を
その位置でアクチベートするように望む場合には、ユー
ザは、オブジェクトプレゼンテーションフォーマットに
おいてマウス入力装置で２回クリックするか、又はコン
テナーアプリケーションメニューを用いてオブジェクト
におけるアクションを選択することができる。図８は、
ユーザがメニューを使用してスプレッドシートオブジェ
クト305をその位置でアクチベートできるようにする１
つの方法を示している。ユーザがコンテナーアプリケー
ション（ワードプロセスアプリケーション）のEditメニ
ュー802からメニュー項目「Excel Worksheet Objec
t」803を選択し、そして「Excel Worksheet Object」
サブメニュー804からいずれかのアクションを選択する
ときには、ワードプロセスアプリケーションは、スプレ
ッドシートアプリケーションを呼び出して、スプレッド
シートオブジェクトをその位置でアクチベートする。

スプレッドシートオブジェクト305をアクチベートす
るプロセスは、多数のステップで行われる。第１に、ワ
ードプロセスアプリケーションのフレームウインドウに
対するウインドウ手順が、その基礎となるウインドウシ
ステムにより、オブジェクトアクションサブメニュー80
4におけるメニュー項目のユーザ選択に応答して呼び出
される。（例えば、図14を参照されたい。）第２に、メ
ニュー事象を受け取ると、ウインドウ手順は、ファンク
ションProcess_Object_Activationを呼び出す。（例え
ば、ステップ1407、1411及び1413を参照されたい。）第
３に、ファンクションProcess_Object_Activationは、
オブジェクトリンク及び埋め込みAPIのファンクションO
bjectLoadを用いてスプレッドシートオブジェクト305に
対するデータをロードする。最後に、ファンクションPr
ocess_Object_Activationプログラムは、スプレッドシ
ートオブジェクト305のDoVerb方法を呼び出して、選択
されたアクションを実行するようにスプレッドシートア
プリケーションに要求する。

図27は、ファンクションProcess_Object_Activation
を具現化するフローチャートである。このファンクショ
ンは、選択されたオブジェクトをロードし、そしてその
DoVerb方法を呼び出して、選択されたアクションを実行
する。ステップ2701において、このファンクションは、
オブジェクトリンク及び埋め込みAPIのファンクションO
bjectLoadを呼び出し、オブジェクトの記憶に対するポ
インタと、それがIOLEObjectインターフェイスを希望す
るという指示とをそれに通す。ファンクションObjectLo
adは、ロードされたオブジェクトのIOLEObjectインター
フェイスに対するポインタを返送する。ステップ2702に
おいて、このファンクションは、コンテニーオブジェク
トのSetClientSite方法を呼び出して、その関連する親
コンテニーオブジェクトインターフェイス（pclientsit
e）に対するポインタをコンテニーオブジェクトに手渡
す。ステップ2703において、このファンクションは、ロ
ードされたオブジェクトのIOLEObject::DoVerb方法を呼
び出し、選択されたアクション、そのアクションがダブ
ルクリックによって選択されたかどうかの指示、及びオ
ブジェクトに対して既に形成されているIOLEClientSite
インターフェイスをそこに通す。次いで、このファンク
ションは復帰となる。

図28は、オブジェクトリンク及び埋め込みAPIファン
クションObjectLoadの具現化を示すフローチャートであ
る。このファンクションは、オブジェクトのメモリ内イ
ンスタンスを形成し、将来の対話についてサーバアプリ
ケーションを準備し、そして指定されたインターフェイ
スに対するポインタを返送する。このファンクション
は、３つのパラメータ、オブジェクトデータがロードさ
れるべき記憶装置に対するポインタ、発呼者が返送を望
むインターフェイスの指示、及びオブジェクトのメモリ
内インスタンスに対する返送ポインタを取り上げる。ス
テップ2801において、このファンクションは、CLASS_ID
を指定の記憶装置から検索する。ステップ2802におい
て、このファンクションは、検索されたCLASS_IDを用い
て、この形式のオブジェクトのメモリ内インスタンスを
形成するためのコードを位置決めする。本発明の好まし
い実施例においては、IOLECreateインターフェイスが各
サーバアプリケーションによって与えられ、それが具現
化するオブジェクトのメモリ内インスタンスを形成す
る。ステップ2803において、このファンクションは、IO
LECreate::CreateInstance方法を呼び出し、オブジェク
トに対するメモリ内構造を形成し、そしてオブジェクト
に対する永続的記憶装置をアクセスするところのIPersi
stStorageインターフェイスに対するポインタを返送す
る。ステップ2804において、このファンクションは、IP
ersistStorage::Load方法を呼び出し、これは、指定さ
れた記憶装置からオブジェクトデータをロードする。ス
テップ2805において、このファンクションはIPersistSt
orage::QueryInterface方法を呼び出し、指定のインタ
ーフェイスを検索すると共に、その検索されたインター
フェイスを返送する。

図29は、IOLEObject::DoVerb方法の典型的な具現化を
示すフローチャートである。この方法は、コンテニーオ
ブジェクトと対話するための主たる方法である。この方
法は、コンテナーアプリケーションと交渉して、イン・
プレース対話を行うと共に、サーバアプリケーションの
ユーザインターフェイスをアクチベートさせる。この方
法は、４つのパラメータ、即ちユーザが選択したアクシ
ョン；ユーザがアクションを選択したときにコンテナー
アプリケーションのウインドウ手順によって受け取られ
るメッセージ構造に対するポインタ；オブジェクトのIO
LEClientSiteインターフェイスに対するポインタ；及び
例えば、サーバアプリケーションが呼び出し時に入力フ
ォーカスを得るべきかどうかについてverb.の実行を制
御する１組のフラグを取り上げる。ステップ2901におい
て、この方法は、IOLEClientSite::QueryInterface方法
を呼び出して、特定のオブジェクトに対するIOLEInPlac
eParentインターフェイスを得る。ステップ2902におい
て、この方法は、IOLEInPlaceParent::CanInPlaceActiv
ate方法を呼び出して、コンテナーアプリケーションが
イン・プレース対話をサポートするかどうかを決定す
る。ステップ2903において、コンテナーアプリケーショ
ンがイン・プレート対話をサポートしない場合には、こ
の方法はステップ2904に続き、さもなくば、この方法は
ステップ2906に続く。ステップ2904において、この方法
は、サーバアプリケーションのフレームウインドウを形
成し表示する。というのは、コンテナーアプリケーショ
ンがイン・プレース対話を実行できないからである。ス
テップ2905において、この方法は、指定されたアクショ
ンの通常の処理を続け、復帰する。ステップ2906におい
て、この方法は、IOLEInPlaceParent::GetWindowContex
t方法を呼び出し、コンテナーアプリケーションに関連
したインターフェイスを得る。ステップ2907において、
この方法は、特定のオブジェクトでイン・プレース対話
をサポートするために形成する必要のあるオブジェクト
ウインドウのサイズを計算する。ステップ2908におい
て、この方法は、IOLEInPlaceParent::GetWindowContex
t方法により返送されたエリアがスケーリング又はクリ
ッピングを必要とするかどうか及び特定のオブジェクト
がこれをサポートできるかどうかを決定する。必要とさ
れるサイズをサポートできる場合には、この方法はステ
ップ2909に続き、さもなくば、この方法は、イン・プレ
ース対話を放棄してステップ2909へ続く。ステップ2909
において、この方法は、IOLEInPlaceParentインターフ
ェイスに対応するウインドウに対するウインドウハンド
ルを検索する。ステップ2910において、この方法は、オ
ブジェクトルートウインドウとして使用されるべきIOLE
InPlaceParentインターフェイスに対応するウインドウ
の子として新たなウインドウを形成する。（例えば、図
13の項目1309を参照されたい。）ステップ2911におい
て、この方法は、特定のオブジェクトに対するユーザイ
ンターフェイスリソースがまだ使用できるかどうか、即
ち割り当てられているがまだ割り当て解除されていない
かどうかを決定する。これらリソースが使用できる場合
には、この方法はステップ2913へ続き、さもなくば、こ
の方法はステップ2912へ続く。ステップ2912において、
この方法は、IOLEInPlaceParent::OnUIActivate方法を
呼び出し、コンテナーアプリケーションが、特定のオブ
ジェクトをその位置でアクチベートする準備においてそ
のユーザインターフェイスリソースを除去できるように
する。ステップ2913において、この方法は、IOLEInPlac
eParent::OnInPlaceActivate方法を呼び出し、コンテナ
ーアプリケーションが、ネスト状オブジェクトをその位
置でアクチベートしたことを記録できるようにする。ス
テップ2914において、この方法は、ファンクションCrea
teNewMenuを呼び出し、新たな複合メニューバーを形成
する（コードテーブル２を参照）。ステップ2915におい
て、この方法は、特定のオブジェクトが付加的なユーザ
インターフェイスツールのアクチベーションを必要とす
るかどうかを決定し、もしそうであれば、ステップ2916
へ続き、さもなくば、ステップ2917へ続く。ステップ29
16において、この方法は、ファンクションCreateObject
Toolbarsを呼び出し、特定のオブジェクトの付加的なユ
ーザインターフェイスツールの位置を交渉しそしてそれ
を配置する（図24を参照）。ステップ2917において、こ
の方法は、ファンクションActivateUIを呼び出し、これ
は、特定のオブジェクトの全てのユーザインターフェイ
スリソースを表示させ（図23を参照）そして復帰とな
る。

5.1.1 多文書インターフェイスアプリケーション
内の位置でのアクチベーション オブジェクトがSDIコンテナーアプリケーションから
アクチベートされたと仮定してコンテニーオブジェクト
のアクチベーションについて上記した。一方、オブジェ
クトがMDIコンテナーアプリケーション（このアプリケ
ーションは、定義により、多数の複合文書と同時に対話
できる）内でアクチベートされる場合には、オブジェク
トを含む文書（MDI）ウインドウがアクチベート又はデ
アクチベートされるときにアクチベーション及びデアク
チベーションが生じる。文書ウインドウに対するウイン
ドウ手順は、ユーザがウインドウを選択する（例えば文
書ウインドウのタイトルバーにおいてクリックすること
により）ときに、その基礎となるウインドウシステムか
らアクチベーションメッセージを受け取る。文書ウイン
ドウに対するウインドウ手順は、ユーザが次いで異なる
ウインドウを選択するときにデアクチベーションメッセ
ージを受け取る。これらのメッセージに応答して、文書
ウインドウに対するウインドウ手順は、ファンクション
（例えばProcess_Activation_Message）を呼び出し、文
書ウインドウ及びその中に含まれたアクチベートされた
オブジェクトのアクチベーション及びデアクチベーショ
ンを実行する。

図30は、アクチベーション及びデアクチベーションメ
ッセージを処理するためにMDI文書ウインドウのウイン
ドウ手順によって呼び出されたファンクションProcess_
Activation_Messageの具現化を示すフローチャートであ
る。１つの実施例において、文書ウインドウハンドルが
ファンクションに対するパラメータとして通される。こ
のファンクションは、ウインドウが最後にアクティブと
なったときに既にその位置でアクチベートされたオブジ
ェクトをウインドウが含むかどうかを決定する。もしそ
うであれば、ファンクションは、そのオブジェクトをア
クチベート又はデアクチベートし、さもなくば、文書ウ
インドウをその通常の形態でアクチベート又はデアクチ
ベートする。ステップ3002において、このファンクショ
ンは、その通常のウインドウデアクチベーション手順を
実行し、そして復帰となる。ステップ3001において、こ
のファンクションは、ファンクションGetActiveObjectH
wndを呼び出すことにより、既にアクティブな収容オブ
ジェクトがもしあればそれに対しIOLEInPlaceObjectの
オブジェクトインターフェイスを検索する。ステップ30
02において、このファンクションは、オブジェクトイン
ターフェイスがナルであるかどうか決定する。もしナル
であれば、既にアクティブな収容オブジェクトは存在せ
ず、ファンクションはステップ3003へ続き、さもなく
ば、ファンクションはステップ3004へ続く。ステップ30
03では、このファンクションは、文書ウインドウツール
及びメニューを設定するといったその通常のウインドウ
アクチベーション又はデアクチベーション手順を実行
し、そして復帰となる。ステップ3004では、このファン
クションは、指定されたフラグFActiveが真であるかど
うか決定する。フラグFActiveが真である場合は、既に
アクティブな収容オブジェクトをアクチベートすべきで
あり、このファンクションはステップ3005に続き、さも
なくば、オブジェクトをデアクチベートすべきであり、
ファンクションはステップ3006に続く。ステップ3005で
は、このファンクションは、検索されたインターフェイ
スのIOLEInPlaceObject::Activate方法を呼び出して、
既にアクチベートされたオブジェクトがそれ自体アクチ
ベートするように要求し、そして復帰となる。ステップ
3006では、このファンクションは、検索されたインター
フェイスのIOLEInPlaceObject::Activate方法を呼び出
して、既にアクチベートされたオブジェクトがそれ自体
デアクチベートするように要求し、そして復帰となる。

5.2 プルダウンメニューメッセージハンドリングの
ユーザ選択 ユーザがオブジェクトをその位置でアクチベートした
後に、ユーザは、コンテナーアプリケーションのメニュ
ーバー（これは複合メニューバーである）を介してアク
ションを選択することによりコンテナーアプリケーショ
ン内のオブジェクトと対話する。メニューのあるものは
サーバアプリケーションに属しておりそして他のメニュ
ーはコンテナーアプリケーションに属しているので、コ
ンテナーアプリケーションのフレームウインドウのウイ
ンドウ手順は、メニュー入力事象をコンテナーアプリケ
ーション内のファンクションに送信すべきかサーバアプ
リケーション内のファンクションに送信すべきか判断し
なければならない。このために、オブジェクトリンク及
び埋め込みAPIのファンクションObjectSetMenuDescript
orがサーバアプリケーションによって呼び出されたとき
にこのファンクションによって特殊なメッセージハンド
ラーがインストールされ、新たに形成された複合メニュ
ーバーをインストールする。この特殊なメッセージハン
ドラーは、これがインストールされると、コンテナーア
プリケーションのフレームウインドウに対する新たなウ
インドウ手順となる。従って、そのフレームウインドウ
に対応するコンテナーアプリケーションによって受け取
られた全てのメッセージは、その後に、先ず、特殊なメ
ッセージハンドラーへ送られる。この特殊なメッセージ
ハンドラーは、次いで、受け取ったメッセージ事象をど
のアプリケーションへ送るべきかを判断する。

コードテーブル５は、オブジェクトリンク及び埋め込
みAPIにより与えられる特殊なメッセージハンドラーの
具現化を示している。ライン３ないし54は、受け取った
メッセージの形式に基づくケースステートメントを具現
化する。ライン28ないし49は、ハンドラーがその基礎と
なるウインドウシステムからメニューコマンドメッセー
ジを受け取ったときにメッセージを適切に送れるように
する初期化を与える。ライン４ないし27及びライン50な
いし53は、メニューコマンドメッセージが受け取られた
ときに基本的なルートメカニズムを与える。ライン29に
おいて、共用メニューデータ構造に対するハンドルは、
コンテナーアプリケーションのフレームウインドウの特
性から検索される。ライン32ないし37において、ハンド
ラーは、複合メニューバーのエントリーをウォークし、
その入力メッセージで受け取られたメニューとの一致を
試みる。このプロセスにおいて、遭遇するメニューの数
を追跡する（ライン36）。ループを出たときにメニュー
が見つかった場合には、変数カウントは、左から始めて
選択されたメニューの数を表す。このカウントは、次い
で、ライン43ないし48に含まれたループに使用され、メ
ニューがどの記述子エレメントに属するかを決定する。
より詳細には、記述子の各インデックスに記憶された値
がチェックされ、そしてメニューの数がその値以下であ
って且つ左側のインデックスにおいて記述子に記憶され
た値より大きい場合には、正しい記述子エレメントが位
置決めされる。正しいエレメントが分かると、ハンドラ
ーは、コンテナーアプリケーションファンクションを呼
び出さねばならないかサーバアプリケーションファンク
ションを呼び出さねばならないかに対応する指示子を検
索する。この指示子は、次いで、ライン45及び47におい
て変数saveMenuRoutineにセーブされる。メニューのニ
ューモニックス（mneumonics）（システムメニューキー
シーケンスを含む）を適切に処理するためのハンドラー
として、このハンドラーは、メニューコマンドメッセー
ジに応答するときに入力フォーカスをフレームウインド
ウにセットする。

メニューのニューモニックスは、マウスを使用するの
ではなく、キーボードを使用してメニューをアクセスす
る方法を与える「Alt.−,F.N.」のようなキーシーケン
スである。通常は、メニュー項目は、例えば、ウインド
ウズ3.1においてアンダーラインを付したその独特のニ
ューモニックスとして指定された１つの文字を有する。
メニュー項目をアクセスするために、その独特のニュー
モニックスがその収容するメニューのニューモニックス
に添付される。全キーシーケンスの前にはシステムキー
があり、これはユーザがメニューニューモニックスをタ
イプ入力したい旨をシステムに知らせる。メニューニュ
モニックスは、イン・プレース対話がその基礎となる幾
つかのウインドウシステムで具現化されるときに特殊な
問題を課する。より詳細には、変更されない条件のもと
で、コンテニーオブジェクトがその位置でアクチベート
されたときに、システムキー（ウインドウズ3.1におけ
る「ALT」キー）及び他のナビゲーションキー除く全て
のキーボード入力がオブジェクトルートウインドウに対
するウインドウ手順に送られる（図13の項目1309を参照
されたい）。というのは、オブジェクトルートウインド
ウには、オブジェクトがアクチベートされたときに入力
フォーカスが与えられるからである。しかしながら、そ
の基礎となるウインドウシステムはシステムキーをコン
テナーアプリケーションフレームウインドウのウインド
ウ手順に送る。というのは、このキーは特殊に手渡しさ
れるからである。従って、コンテナーアプリケーション
は、システムキーシーケンスの選択されたメニュー項目
に対応するキー入力を受け取ることはない。例えば、メ
ニューニューモニックスのキーシーケンスがALT.−,m
（「move」に対し）である場合には、「ALT」キーの押
圧がコンテナーアプリケーションへ送られそして「−」
及び「ｍ」キーの押圧がサーバアプリケーションへ送ら
れる。この問題を解消するために、入力フォーカスはコ
ンテナーアプリケーションフレームウインドウに一時的
にセットされ、一方、フレームウインドウ手順はメニュ
ー事象を処理する。この解決策の一例がライン５、39及
び40に示されている。

ライン４ないし14において、ハンドラーがメニューコ
マンドを受け取るときに、ハンドラーは、先ず、通常の
プロセスを続けられるように入力フォーカスを回復させ
る。次いで、ハンドラーは、SaveMenuRoutineにセーブ
された指示子をチェックする。これが、メニューがサー
バアプリケーションに属することを指示する場合には、
ハンドラーはオブジェクトウインドウのウインドウ手順
を呼び出し、さもなくば、元のコンテナーアプリケーシ
ョンウインドウ手順を呼び出す。より詳細には、ライン
７において、ハンドラーは、コンテナーアプリケーショ
ンのフレームウインドウの特性として記憶されたオブジ
ェクトのウインドウハンドルを得る。ライン８におい
て、ハンドラーは、オブジェクトウインドウにメッセー
ジを非同期で発信し、元のメッセージ及び元のパラメー
タを送る。ライン11において、指示子がサーバアプリケ
ーションを特定しない場合には、ハンドラーは、コンテ
ナーアプリケーションのフレームウインドウの元のウイ
ンドウ手順を検索し、そしてライン12において、この手
順を、指定されたメッセージ及びパラメータで呼び出
す。コンテナーアプリケーションのフレームウインドウ
の元のウインドウ手順は、新たなウインドウ手順におい
てインストールされたObjectSetMenuDescriptorへの呼
び出しにおいてセーブされる。

ライン15ないし27において、ハンドラーは、他のメニ
ュー関連メッセージを受け取ると、ライン６ないし13で
与えられたのと同様にコンテナー又はオブジェクトアプ
リケーションへメッセージを適宜発送する。ライン50な
いし53において、他の種類のメッセージが受け取られた
場合には、古いウインドウ手順が検索され、メッセージ
及びパラメータがそこに送られる。

5.3 その位置でのデアクチベーション手順 ユーザが、その位置でアクチベートされるオブジェク
ト以外のエリアを選択すると、オブジェクトがデアクチ
ベートされる。一般に、この振る舞いは、ユーザがコン
テナーアプリケーションのウインドウか又はMDIコンテ
ナーアプリケーションの場合には異なる文書ウインドウ
の別のエリアにおいてマウスボタンでクリックするとき
に生じる。それ故、一般的に述べると、イン・プレース
対話APIのデアクチベーション方法は、マウスボタン事
象を処理するためにコンテナーアプリケーションによっ
て呼び出されるファンクションから呼び出される。

図31は、Process_Mouse_LButtonDownファンクション
の具現化を示すフローチャートである。このファンクシ
ョンは、左のボタンダウンメッセージの受信によって信
号される入力事象を処理する。当業者であれば、このよ
うなファンクションは、いずれかの種類の入力事象を受
信した際に呼び出すことができそして他の事象は選択及
び選択解除に使用できることが明らかであろう。ステッ
プ1301では、このファンクションは、コンテナーアプリ
ケーションがアクチベートしようとしていることを指示
するフラグをセットする。このフラグは、ネスト状デア
クチベーションの呼び出しのシーケンス中に使用され、
ネスト状アクチベーションの場合に正しいユーザインタ
ーフェイスリソースが表示されるように確保する。ステ
ップ3102において、このファンクションは、フラグACTI
VATED_SOMEONEをチェックして、オブジェクトがその位
置でアクチベートされたかどうかを判断し、もしそうで
あれば、ステップ3104へ続き、さもなくば、ステップ31
03へ続く。ステップ3103では、このファンクションは、
その通常の左ボタンダウン事象処理を実行し、そして復
帰となる。ステップ3104では、このファンクションは、
現在アクチベートされたオブジェクトに対しIOLEInPlac
eObjectインターフェイスを検索する。ステップ3105に
おいて、このファンクションは、オブジェクトのIOLEIn
PlaceObject::InPlaceUIDeactivate方法を呼び出す。こ
のファンクションは、次いで、ステップ3103へ続く。

図21に示すように、現在アクチベートされたオブジェ
クトのIOLEInPlaceObject::InPlaceUIDeactivate方法
は、次いで、このIOLEInPlaceParent::OnUIDeactivate
方法を呼び出して、コンテナーアプリケーションがその
ユーザインターフェイスリソースをインストールできる
ようにする。このデアクチベーションは、最上位レベル
のコンテナー又はアクチベートしようとしているオブジ
ェクトのコンテナーのいずれかに到達するまで上方にネ
スト構成になる。（図19を参照されたい）。例えば、図
４を参照すると、埋め込まれたスプレッドシートオブジ
ェクト405内に示された埋め込まれたチャートオブジェ
クト409が現在アクチベートされたオブジェクトであり
そしてユーザがスプレッドシートオブジェクト405を選
択してこれをその位置でアクチベートする場合は、チャ
ートのIOLEInPlaceObject::InPlaceUIDeactivate方法が
呼び出され、これは、次いでスプレッドシートのIOLEIn
PlaceObject::OnUIDeactivate方法を呼び出す。この後
者の方法は図４に示すようにスプレッドシートオブジェ
クトに対するユーザインターフェイスをインストールす
る。一方、ユーザが複合文書内のどこかでクリックした
場合には、スプレッドシートのIOLEInPlaceObject::OnU
IDeactivate方法は、複合文書のIOLEInPlaceObject::On
UIDeactivate方法を呼び出す。この後者の方法は、ワー
ドプロセスユーザインターフェイスをインストールす
る。というのは、このオブジェクトは最上位レベルのコ
ンテナーオブジェクトだからである。

コンテナーアプリケーションは、表示されたコンテナ
ーオブジェクトを垂直又は水平にスクロールするための
スクロールバーを表示することができる。これらスクロ
ールバーは、コンテナーウインドウの一部分である。コ
ンテナーオブジェクトがアクチベートされたコンテニー
オブジェクトを有する場合には、ユーザがコンテニーオ
ブジェクトの外側のエリアでクリックしたときに、コン
テニーオブジェクトはデアクチベートされる。好ましい
実施例では、コンテナーアプリケーションは、クスロー
ルバーメッセージを受け取る際に、コンテニーオブジェ
クトをデアクチベートしない。むしろ、コンテナーアプ
リケーションは、スクロールを行い、入力フォーカスが
コンテニーオブジェクトと共に留まるよう確保する。

5.4 コンテナーアプリケーションを閉じる コンテナーアプリケーションが、既にアクチベートさ
れたオブジェクトを再アクチベートする開放（undo）オ
ペレーションをもはや実行できなくなった後であって、
且つコンテナーアプリケーションがユーザによって閉じ
られる前のある時間に、コンテナーアプリケーション
は、既にアクチベートされたオブジェクトに関連したユ
ーザインターフェイスリソースを永久的に割り当て解除
する。これらのリソースを割り当て解除するために、コ
ンテナーアプリケーションは、既にアクチベートされた
オブジェクトに関連したIOLEInPlaceObject::InPlaceDe
activate方法を呼び出す。この方法は、次いで、共用メ
ニューデータ構造と、複合メニューバーに関連したメニ
ューとを割り当て解除する。（図20及びそれに関連した
説明を参照されたい。） 5.5 モードレスダイアログとの対話 その位置でアクチベートされたオブジェクトであって
そのサーバアプリケーションがモードレスダイアログを
表示しているようなオブジェクトとユーザが対話すると
きに、ユーザがそれ自身のモードダイアログを表すコン
テナーアプリケーションメニューからメニュー項目を選
択したい場合には、コンテナーアプリケーションはサー
バアプリケーションのモードレスダイアログを一時的に
隠す。モードレスダイアログボックスが隠されるのは、
ユーザが同時に表示される２つのダイアログボックスを
見て混乱しそしてどのボックスに入力が送られるか分か
らないからである。というのは、サーバ及びコンテナー
アプリケーションは、１つのアプリケーションとして現
れることを意味するからである。又、モードダイアログ
は、他のダイアログとの競合を回避するようにプログラ
ムされていない。というのは、慣例的なアプリケーショ
ンにおいては、その基礎となるウインドウシステムが単
一のアプリケーション内のモードダイアログの外側の入
力を禁止するからである。イン・プレース対話を使用す
る場合には、２つのアプリケーションが共働して１つに
見えるので、このような競合は自動的に回避される。そ
れ故、アプリケーションは、モードダイアログとモード
レスダイアログとの間の競合を回避するように共働しな
ければならない。例えば、ユーザがスプレッドシートア
プリケーションのEditメニューにおける「Find...」メ
ニュー項目を選択し、サーバアプリケーションによって
モードレスダイアログが表示されると仮定する。ここ
で、ユーザが複合文書の一部分をプリントアウトしよう
とし、従って、ユーザが、ワードプロセス（コンテナ
ー）アプリケーションに属するFileメニュー上の」Prin
t...」メニュー項目を選択すると仮定する。ワードプロ
セスアプリケーションは、両方のダイアログが同時に表
示されないのが好ましいので、「Find...」ダイアログ
を隠す。これを行うために、ワードプロセスアプリケー
ションは、スプレッドシートアプリケーションのIOLEIn
PlaceObject::EnableModeless方法を呼び出して、モー
ドレスダイアログを隠すように要求する。次いで、コン
テナーアプリケーションが「Print...」ダイアログの処
理を終了した後に、EnableModeless方法を呼び出して、
モードレスダイアログを再表示する。

サーバアプリケーションがコンテナーアプリケーショ
ンのモードレスダイアロスを隠す必要がある場合にも同
様の状態が生じ得る。この場合には、IOLEInPlaceFram
e::EnableModeless方法が使用される。

5.6 アクセラレータキーの組合せの取り扱い 本発明の好ましい実施例においては、その基礎となる
ウインドウシステムは、アクセラレータキー組合せと称
する概念をサポートし、ユーザがキーボードショートカ
ットを介してメニューコマンドを呼び出すことができる
ようにする。アクセラレータキー組合せは、特定のメニ
ューコマンドを呼び出すことと同等であるようにアプリ
ケーションによって指定された一連のキーである。例え
ば、「CNTRL」キーを押した後に「Ｎ」キーを押すこと
より成るキーのシーケンスは、「File」メニュー上のメ
ニューコマンド「New」に変換される。典型的なシステ
ムにおいて、アクセラレータキー組合せは、ユーザによ
って指定でき、アプリケーション内で独特である必要が
ある。

一般に、アクセラレータキー組合せ（アクセラレー
タ）は、アプリケーションのメッセージポンプにおいて
処理される（図14のステップ1402を参照）。典型的なメ
ッセージポンプは、その基礎となるウインドウシステム
を呼び出してアクセラレータ変換テーブルをそこに通
し、ウインドウシステムが、アクセラレータがどのメニ
ュー項目コマンドに対応するかを決定するようにさせ
る。ウインドウシステムは、次いで、それにより得たメ
ニューコマンドを適当なウインドウ手順に送信する。

オブジェクトリンク及び埋め込みイン・プレース対話
APIではアクセラレータに対して問題が生じ得る。先
ず、サーバアプリケーションはそのコンテナーアプリケ
ーションのプロセススペース内でオブジェクトハンドラ
ーとして具現化できるので、コンテナーアプリケーショ
ンは、サーバアプリケーションがそれ自身のアクセラレ
ータを変換する機会をもつよう確保しなければならな
い。好ましくは、サーバアプリケーションには、サーバ
アプリケーションがその位置でアクチベートされたとき
にあいまいなアプリケーションアクセラレータの処理に
おいてコンテナーアプリケーションより高い優先順位が
与えられる。又、サーバアプリケーションがそれ自身の
プロセススペースにおいて具現化される場合には、それ
が確認できないアクセラレータをコンテナーアプリケー
ションに通さねばならない。

この問題を解決するために、コンテナーアプリケーシ
ョン及びサーバアプリケーションのメッセージポンプ
は、アプリケーションアクセラレータを変換する機会を
互いに許すように変更される。コードテーブル６及び７
は、サーバアプリケーションが個別のプロセスとして実
行されるときに適用できるサーバアプリケーションのメ
ッセージポンプに対する変更を示している。更に、コー
ドテーブル８は、サーバアプリケーションが同じプロセ
ス内でコンテナーアプリケーションとして（オブジェク
トハンドラーとして）実行されるときに適用できるコン
テナーアプリケーションのメッセージポンプに対する変
更を示している。

コードテーブル６は、その位置でアクチベートされた
オブジェクトのメッセージポンプに対する変更の具現化
を示す。これらの変更は、サーバアプリケーションが、
コンテナーアプリケーションに、サーバアプリケーショ
ン（個別のプロセス）が到来メッセージを最終的に破棄
する前にアプリケーションアクセラレータを変換する機
会を与えることができるようにする。ライン２におい
て、サーバアプリケーションは、それ自身の変換テーブ
ル（変数hAccelに記憶された）を用いてアクセラレータ
を変換するよう試みる。ライン３において、変換すべき
アクセラレータがなかったか、又はサーバアプリケーシ
ョンの変換テーブルにアクセラレータが見つからなかっ
たことにより、この変換が首尾良くいかなかった場合に
は、サーバアプリケーションは、特殊なオブジェクトリ
ンク及び埋め込みAPIのファンクションObjectTranslate
Acceleratorを呼び出す。このファンクションObjectTra
nslateAcceleratorは、コンテナーアプリケーションに
よってアクセラレータが所望されるかどうか決定し、も
しそうならば、遠隔手順通話を介してコンテナーアプリ
ケーションにメッセージを送信し、アクセラレータを変
換するように要求する。遠隔手順通話メカニズムは、そ
の同期特性により、発呼者（サーバプロセス）が更に入
力を受け取る前にコンテナーアプリケーションがメッセ
ージを処理して復帰するよう確保する。ライン４ないし
５において、コンテナーアプリケーションがアクセラレ
ータを変換しなかった場合には、サーバアプリケーショ
ンが入力メッセージをその通常の形態で処理する（それ
をフィルタして発送する）。

コードテーブル７は、オブジェクトリンク及び埋め込
みAPIのファンクションObjectTtanslateAccleratorの具
現化を示している。このファンクションは、サーバアプ
リケーションがコンテナーアプリケーションにアクセラ
レータを処理する機会を与えることができるようにす
る。同期メッセージ処理に本来ある落とし穴（不定の待
機のような）を回避するために、ObjectTranslateAccel
eratorは、先ず、コンテナーアプリケーションのTransl
ateAccelerator方法を呼び出そうと試みる前にコンテナ
ーアプリケーションがアクセラレータに挿入されたかど
うか調べるチェックを行う。コンテナーアプリケーショ
ンのアクセラレータテーブルは、サーバアプリケーショ
ンによって通された指定のパラメータである。これは、
IOLEInPlaceParent::GetWindowContextに対する通話を
介してサーバアプリケーションにアクセスできる。コン
テナーアプリケーションのTranslateAccelerator方法が
呼び出された場合には、このファンクションは、コンテ
ナーアプリケーションにより返送された値をサーバアプ
リケーションへ戻し、従って、サーバアプリケーション
はメッセージを適切に破棄することができる。

コードテーブル８は、イン・プレート対話をサポート
するコンテナーアプリケーションのメッセージポンプの
典型的な具現化を示す。これらの変更は、コンテナーア
プリケーションが、サーバアプリケーション（コンテナ
ーアプリケーションと同じプロセス内で実行している）
に、コンテナーアプリケーションが到来メッセージを完
全に破棄する前にアプリケーションアクセラレータを変
換する機会を与えることができるようにする。ライン２
において、コードは、コンテナーアプリケーションの文
書ウインドウに関連した現在アクティブなオブジェクト
ウインドウバンドルを検索する。ライン４ないし８にお
いて、アクティブなオブジェクトウインドウハンドルが
ない場合には、コードは、そのオブジェクトウインドウ
ハンドルに対応するIOLEInPlaceObjectTranslateAccele
rator方法を呼び出して、サーバアプリケーションがア
クセラレータキー組合せを変換できるようにする。ライ
ン９ないし11において、サーバアプリケーションがアク
セラレータを変換しないか、又はアクティブなオブジェ
クトがない場合には、コンテナーアプリケーションは、
それ自身の変換テーブル（変数hAccelに記憶された）を
用いてアクセラレータを変換するよう試みる。ライン12
ないし13において、変換すべきアクセラレータが確認さ
れない場合には、コンテナーアプリケーションは、入力
メッセージを通常の形態で処理する（それをフィルタし
て発送する）。

以上、好ましい実施例について本発明を説明したが、
本発明は、この実施例に限定されるものではない。本発
明の精神内での変更が当業者に明らかであろう。本発明
の範囲は、以下の請求の範囲によって限定されるものと
する。

フロントページの続き (72)発明者 マッキチャン バリー ビー アメリカ合衆国 ワシントン州 98110 ベインブリッジ アイランド マンザ ニタ ロード ノースイースト 12730 (72)発明者 マックダニエル リチャード アメリカ合衆国 ペンシルバニア州 15206 ピッツバーグ スタントン ア ベニュー 6017 アパートメント １ (72)発明者 レマラ ラオ ヴィー アメリカ合衆国 ワシントン州 98072 ウッディンヴィル ノースイースト ワンハンドレッドアンドフィフティファ ースト ストリート 19011 (72)発明者 ウィリアムズ アントニー エス アメリカ合衆国 ワシントン州 98053 レッドモンド ノースイースト フォ ーティシックスス ストリート 22542 (56)参考文献 特開 昭62−46365（ＪＰ，Ａ) 特開 昭60−55472（ＪＰ，Ａ) 特開 昭62−72059（ＪＰ，Ａ) 特開 平１−126736（ＪＰ，Ａ) 特開 平２−25969（ＪＰ，Ａ) 特開 平１−234967（ＪＰ，Ａ) Ｗｉｎｄｏｗｓアプリケーション間連 携機構ＯＬＥ，ＮＩＫＫＥＩ ＢＹＴＥ 1992年２月号 Ｐ．239−252 Ｐｅｔｅｒ Ｗａｙｎｅｒ”ＢＲＡＶ Ｅ ＮＥＷ ＤＥＳＫＴＯＰ”ＢＹＴＥ Ｖｏｌ．17，Ｎｏ．14 Ｐ．153−156

Claims (25)

(57)【特許請求の範囲】
1. 【請求項１】コンピュータシステムにおいて、コンテナ
   ーオブジェクト（301、401）内に含まれるコンテニーオ
   ブジェクト（305、405）をアクチベートさせる方法であ
   って、前記コンピューッタシステムは、コードをスケジ
   ュールしおよび実行するオペレーティングシステムを有
   し、前記コンテナーオブジェクトはコンテナーウィンド
   ウ環境（304、404）を伴うコンテナーアプリケーション
   コードを有し、前記コンテナーウィンドウ環境は前記コ
   ンテナーオブジェクトと対話するためのコンテナーリソ
   ース（302、303、402、403）を有し、前記コンテニーオ
   ブジェクトは該コンテニーオブジェクトと対話するため
   のサーバリソースを伴うサーバアプリケーションコード
   を有し、 前記コンテナーアプリケーションコードを実行するステ
   ップであって、前記コンテナーアプリケーションコード
   が前記オペレーティングシステムによって別々にスケジ
   ュールされるステップと、 前記コンテナーウィンドウ環境（304、404）を表示する
   ステップと、 当該表示されたコンテナーウィンドウ環境内で前記コン
   テニーオブジェクト（305、405）を表示するステップ
   と、 前記コンテニーオブジェクト（305、405）をアクチベー
   トさせるステップと を含み、前記表示されたコンテナーウィンドウ環境（40
   4）内で前記複数のサーバリソースを統合しおよび表示
   し、前記サーバリソースは前記サーバアプリケーション
   コードの一部であり、統合された前記サーバリソースの
   中からサーバリソースをユーザが選択するときに、別々
   にスケジュールされたエンティティとして、前記サーバ
   アプリケーションコードが前記サーバリソースの選択を
   実行しおよび処理するように、サーバアプリケーション
   コードが前記オペレーティングシステムによって別々に
   スケジュールされることを特徴とする方法。
2. 【請求項２】前記コンテナーアプリケーションコード
   が、該コンテナーアプリケーションコードによって割り
   当てられ、および管理されるコンテナーメニュー（30
   3）を有し、前記サーバアプリケーションコードは、該
   サーバアプリケーションコードによって割り当てられお
   よび管理されるサーバメニューを有し、前記複数のサー
   バリソースを統合し、および表示するステップは、 複合メニューバー（403）を生成するステップと、 前記サーバメニューおよび前記コンテナーメニューを、
   生成された複合メニューバーに格納するステップと を含むことを特徴とする請求項１に記載の方法。
3. 【請求項３】前記格納するステップが、前記複合メニュ
   ーバー（403）の中のサーバメニューおよびコンテナー
   メニューをインターリーブすることを特徴とする請求項
   ２に記載の方法。
4. 【請求項４】前記コンテナーウィンドウ環境は、複数の
   メニューを表示するメニューバーを有し、複合メニュー
   バーがコンテナーアプリケーションのメニューバーとし
   て表示されることを特徴とする請求項２に記載の方法。
5. 【請求項５】統合された前記サーバリソースの中からの
   サーバリソースの選択に応答して、サーバリソース選択
   を処理するために、別々にスケジュールされたエンティ
   ティとして前記サーバアプリケーションコードを呼び出
   すステップと、 表示された前記コンテナーウィンドウ環境からのコンテ
   ナーリソースの選択に応答して、前記コンテナーアプリ
   ケーションコードを呼び出して、コンテナーリソース選
   択を処理するステップと をさらに含むことを特徴とする請求項１に記載の方法。
6. 【請求項６】表示された前記コンテナーウィンドウ環境
   内でデータを表示するためのウィンドウを、前記コンテ
   ナーアプリケーションコードが有し、該コンテナーアプ
   リケーションコードと交渉して前記ウィンドウ内に前記
   サーバリソースを設置するステップを含むことを特徴と
   する請求項１に記載の方法。
7. 【請求項７】表示すべきサーバリソースを知っている前
   記コンテナーアプリケーションコード無しで、前記コン
   テナーウィンドウ環境（304、404）内で前記複数のサー
   バリソースを統合しおよび表示するステップが、表示以
   前または表示時に実行されることを特徴とする請求項１
   に記載の方法。
8. 【請求項８】前記コンテナーアプリケーションコードお
   よび前記サーバアプリケーションコードが、単一のコン
   ピュータプロセスにおいて別々のスレッドとして実行さ
   れることを特徴とする請求項１に記載の方法。
9. 【請求項９】複数の前記サーバリソースの統合の後、前
   記コンテナーウィンドウ環境（304、404）内で前記コン
   テニーオブジェクトを表示するステップであって、前記
   コンテナーウィンドウ環境は、ハイライトすることで
   （406）、前記サーバリソースがユーザ選択のために利
   用可能であることを報知するステップをさらに含むこと
   を特徴とする請求項１に記載の方法。
10. 【請求項１０】前記コンテナーアプリケーションコード
    はメッセージを受け取りおよび処理するコンテナーメッ
    セージハンドラを有し、前記サーバアプリケーションコ
    ードはメッセージを受け取りおよび処理するサーバメッ
    セージハンドラを有し、前記コンテナーオブジェクトは
    メッセージを受け取りおよび処理するカレントメッセー
    ジハンドラを有し、該カレントメッセージハンドラは初
    期的に前記コンテナーメッセージハンドラにセットされ
    ており、前記複数のサーバリソースを統合しおよび表示
    するステップは、さらに、前記コンテナーオブジェクト
    のカレントメッセージハンドラを特殊メッセージハンド
    ラにセットするステップであって、前記コンテナーリソ
    ースが選択されたときに、前記特殊メッセージハンドラ
    がコンテナーリソース選択メッセージを前記コンテナー
    メッセージハンドラに送り、前記サーバリソースが選択
    されたときにサーバリソース選択メッセージを前記サー
    バメッセージハンドラに送るステップを含むことを特徴
    とする請求項１に記載の方法。
11. 【請求項１１】前記コンテナーウィンドウ環境はウィン
    ドウを有し、前記サーバアプリケーションコードは、ウ
    ィンドウを伴うサーバウィンドウ環境を有し、 ユーザ入力を受け付けるための入力フォーカスを有する
    サーバウィンドウ環境ウィンドウを指定するステップ
    と、 ユーザからメニューコマンドを受け付けるステップと、 該メニューコマンドの受け付けに応答して、ユーザ入力
    を受け付けるための入力フォーカスを有するコンテナー
    ウィンドウ環境ウィンドウを指定するステップと、 メニューニーモニックを受け付けるステップと、 該メニューニーモニックの受け付けに応答して、ユーザ
    入力を受け付けるための入力フォーカスを有するサーバ
    ウィンド環境ウィンドウを再指定するステップと を含むことを特徴とする請求項１に記載の方法。
12. 【請求項１２】前記コンテナーウィンドウ環境ウィンド
    ウがフレームウィンドウであることを特徴とする請求項
    11に記載の方法。
13. 【請求項１３】前記コンピュータシステムはキーを入力
    するためのキーボードを有し、前記コンテナーアプリケ
    ーションコードは前記コンテナーリソースを選択するた
    めの複数のアクセラレータキーの組合せを有し、前記サ
    ーバアプリケーションコードはサーバリソースを選択す
    るための複数のアクセラレータキーの組合せを有し、さ
    らに、前記コンテナーアプリケーションコードがアクセ
    ラレータキーの組合せを受け付けたときに、別々にスケ
    ジュールされたサーバアプリケーションコードを呼び出
    して前記サーバリソースを選択するか否かを決定するス
    テップを含むことを特徴とする請求項１に記載の方法。
14. 【請求項１４】前記コンテニーオブジェクトをアクチベ
    ートさせるステップは、さらに、前記コンテニーオブジ
    ェクトを選択するステップと、 前記コンテニーオブジェクト上で実行すべきオペレーシ
    ョンを特定するステップと を含むことを特徴とする請求項１に記載の方法。
15. 【請求項１５】コンテナーオブジェクト（301、401）内
    に含まれるコンテニーオブジェクト（305、405）をアク
    チベートさせるコンピュータシステムであって、該コン
    ピュータシステムは、コードをスケジュールしおよび実
    行するオペレーティングシステムを有し、前記コンテナ
    ーオブジェクトはコンテナーウィンドウ環境（304、40
    4）を伴うコンテナーアプリケーションコードを有し、
    前記コンテナーウィンドウ環境はコンテナーオブジェク
    トと対話するためのコンテナーリソース（302、303、40
    2、403）を有し、前記コンテニーオブジェクトは該コン
    テニーオブジェクトと対話するためのサーバリソースを
    有するサーバアプリケーションコードを有し、 前記コンテナーウィンドウ環境（304、404）を表示する
    手段と、 表示された前記コンテナーウィンドウ環境（304、404）
    内で前記コンテニーオブジェクトを表示する手段と、 表示された前記コンテナーウィンドウ環境内で前記コン
    テニーオブジェクト（305、405）をアクチベートさせる
    手段と、 前記表示されたコンテナーウィンドウ環境（404）内で
    複数の前記サーバリソースを統合しおよび表示する手段
    と、 統合されおよび表示された前記サーバリソースの中から
    サーバリソースが選択されたときに、別々にスケジュー
    ルされたエンティティとしてサーバアプリケーションを
    実行し、サーバリソース選択を処理するための手段と 前記コンテナーアプリケーションコードと前記サーバア
    プリケーションコードとの間で通信をする手段と を含むことを特徴とするコンピュータシステム。
16. 【請求項１６】前記コンテナーアプリケーションコード
    は、該コンテナーアプリケーションコードによって割り
    当てられおよび管理されるコンテナー手段（303）を有
    し、前記サーバアプリケーションコードは、該サーバア
    プリケーションコードによって割り当てられおよび管理
    されるサーバメニューを有し、前記統合しおよび表示す
    る手段は複合メニューバー（403）を生成しおよび複合
    メニューバー内にサーバメニューおよびコンテナーメニ
    ューを格納するための手段を含むことを特徴とする請求
    項15に記載のコンピュータシステム。
17. 【請求項１７】前記生成しおよび格納するための手段
    が、複合メニューバー（403）のサーバメニューおよび
    コンテナーメニューをインターリーブするための手段を
    含むことを特徴とする請求項16に記載のコンピュータシ
    ステム。
18. 【請求項１８】前記コンテナーウィンドウ環境は、複数
    のメニューを表示するメニューバーを有し、複合メニュ
    ーバーが、前記コンテナーウィンドウ環境のメニューバ
    ーとして表示されることを特徴とする請求項15に記載の
    コンピュータシステム。
19. 【請求項１９】表示された前記コンテナーウィンドウ環
    境から前記コンテナーリソースが選択されたときに、前
    記コンテナープリケーションコードを実行して前記コン
    テナーリソースの選択を処理する手段をさらに含むこと
    を特徴とする請求項15に記載のコンピュータシステム。
20. 【請求項２０】前記コンテナーアプリケーションコード
    は、前記コンテナーウィンドウ環境内でデータを表示す
    るためのウィンドウ（304）を有し、前記統合しおよび
    表示する手段は、前記コンテナーアプリケーションコー
    ドと交渉して前記サーバリソースをウィンドウ内に設置
    する手段を含むことを特徴とする請求項15に記載のコン
    ピュータシステム。
21. 【請求項２１】前記コンテナーウィンドウ環境内で複数
    のサーバリソースを統合しおよび表示する手段による処
    理が、表示すべきサーバリソースを知っている前記コン
    テナーアプリケーションコード無しで、表示以前または
    表示時に、実行されることを特徴とする請求項15に記載
    のコンピュータシステム。
22. 【請求項２２】前記コンテナーアプリケーションコード
    および前記サーバアプリケーションコードが、単一のコ
    ンピュータプロセスにおいて別々のスレッドとして実行
    されることを特徴とする請求項15に記載のコンピュータ
    システム。
23. 【請求項２３】前記サーバリソースがユーザ選択に利用
    可能であることをハイライトすることで（406）報知す
    る前記コンテナーウィンドウ環境内で、前記コンテニー
    オブジェクトを表示する手段をさらに含むことを特徴と
    する請求項15に記載のコンピュータシステム。
24. 【請求項２４】前記コンピュータシステムはキーを入力
    するためのキーボードを含み、前記コンテナーアプリケ
    ーションコードは、コンテナーリソースを選択するため
    の複数のアクセラレータキーの組合せを有し、１つのア
    クセラレータキーの組合せを受け取ったときに、別々に
    実行されたエンティティとして前記サーバアプリケーシ
    ョンコードを呼び出して前記サーバリソースを選択する
    か否かを決定する手段を含むことを特徴とする請求項15
    に記載のコンピュータシステム。
25. 【請求項２５】前記アクチベートさせるための手段が、
    前記コンテニーオブジェクトを選択し、および前記コン
    テニーオブジェクトに対して実行すべきオペレーション
    を特定することを特徴とする請求項15に記載のコンピュ
    ータシステム。