JP2012515961A - マルチタブアプリケーションにおけるメッセージ対話を実現する方法およびシステム - Google Patents

Abstract

マルチタブアプリケーションにおけるメッセージ対話を実現する方法が開示される。方法は、トップウインドウとして、マルチタブアプリケーションにおけるタブに対応するページウインドウを生成すること（Ｓ２０１）と、ページウインドウに関連したメッセージ対話を実行すること（Ｓ２０２）と、を含む。マルチタブアプリケーションにおいてメッセージ対話を実現するシステムもまた開示される。
【選択図】図２

Description

本発明はマルチタブアプリケーションプログラミングの分野に関し、より詳細には、マルチタブアプリケーションプログラムにおけるメッセージ対話を実現する方法およびシステムに関する。

ブラウザはしばしば、ユーザがインターネットにアクセスするための最も共通に用いられる入口となる。多くの場合に、ユーザは多くのウェブページに同時に注意を払うことが可能となることを望む。ディスプレイスクリーンのサイズが限られているため、図１で示すようにマルチタブブラウザが開発されている。このマルチタブブラウザにおいては、各タブがウェブページに対応し、ユーザは特定の時刻に１つのウェブページのみのコンテンツに集中することができる。しかしながら、ユーザが他のウェブページのコンテンツに集中したい場合は、ユーザはタブを切り換えることのみを要する。

このタイプのマルチタブブラウザは、ユーザがウェブページを見るための利便を提供することができるが、ページハンギングと呼ばれるある状態（すなわち、ユーザがウェブページ上の動作、例えばページのスクロールやリンクのクリックなどを行えなくなる）の蔓延がしばしば発生する。すなわち、単一のページウインドウがハングした場合、該単一のページウインドウのハングに伴って他のページウインドウもまたハング状態となる。例えば、ユーザが１０のウェブページを開いており現在のページがＳｏｈｕホームページである場合、ユーザが現在のページを閲覧しているとき、現在のページが突然ハングしたとするならば、ユーザは他の９つのウェブページを動作させることができない。この時点では、これらのページの閲覧を続けるためには、ユーザは他の９つのページの閲覧を取り消し、閲覧処理を終了させ、ブラウザを再起動し、９つのウェブページを再び開かなければならない。

本発明は、マルチタブアプリケーションプログラムにおけるメッセージ対話を実現する方法およびシステムを提供するためのものであり、従来技術における、単一のページウインドウがハングした場合に該単一のページウインドウのハングに伴って他のページウインドウもまたハング状態となる問題を解決することができる。

この目的を達成するために、本発明は以下の特徴を提供する。

マルチタブアプリケーションプログラムにおけるメッセージ対話を実行する方法は、
１つ以上のトップレベルウインドウとして、マルチタブアプリケーションプログラムにおける各タブに対応する１つ以上のページウインドウを生成することと、
１つ以上の前記ページウインドウに関連するメッセージ対話を実行することと、を含む。

好ましくは、１つ以上のトップレベルウインドウとして、マルチタブアプリケーションプログラムにおける各タブに対応するページウインドウを生成することが、
前記マルチタブアプリケーションプログラムのメインフレームウインドウと同じレベルに、１つ以上のトップレベルウインドウとして、マルチタブアプリケーションプログラムにおける各タブに対応する１つ以上の前記ページウインドウを生成することをさらに含む。

好ましくは、前記ページウインドウに関連する前記メッセージ対話を実行することが、
前記マルチタブアプリケーションプログラムのメインフレームウインドウによって、１つ以上のメッセージをノンブロッキングモードで前記ページウインドウに送信することを含む。

好ましくは、前記ノンブロッキングモードは、
タイムアウトメカニズムと共に、非同期メッセージ送信モードまたは同期メッセージ送信方法を含む。

好ましくは、前記ページウインドウに関連する前記メッセージ対話を実行することが、
前記マルチタブアプリケーションプログラムのメインフレームウインドウと１つ以上の前記ページウインドウの間にマッピング関係を生成し、記憶することと、
前記メインフレームウインドウによって、前記メインフレームウインドウと１つ以上の前記ページウインドウの間の前記マッピング関係に基づいて、１つ以上のメッセージを前記ページウインドウに送信することと、
受信されたメッセージに対応する１つ以上の動作を実行するように、１つ以上の前記ページウインドウをトリガすることと、を含む。

好ましくは、前記方法は、前記マルチタブアプリケーションプログラムのメインフレームウインドウの位置およびサイズと合致させるように、前記ページウインドウの位置およびサイズを調整することをさらに含む。

好ましくは、前記方法は、タブに対応するページウインドウのハングを判定した場合、ユーザにプロンプトで示すことをさらに含む。

好ましくは、１つ以上のトップレベルウインドウとして、前記マルチタブアプリケーションプログラムにおける各タブに対応する１つ以上のページウインドウを生成することが、
前記マルチタブアプリケーションプログラムにおける新しいタブを生成する場合、トップレベルウインドウとして前記新しいタブに対応するページウインドウを生成することをさらに含む。

好ましくは、前記マルチタブアプリケーションプログラムは、マルチタブウェブページブラウザ、マルチタブドキュメントエディタ、またはマルチタブリーダを含む。

好ましくは、前記マルチタブアプリケーションプログラムにおける複数の前記タブに対応する複数の前記ページウインドウが、異なるスレッドに属し、
および／または、
前記マルチタブアプリケーションプログラムのメインフレームウインドウと、複数の前記タブに対応する１つ以上の前記ページウインドウが、異なるスレッドに属する。

好ましくは、トップレベルウインドウとして、前記マルチタブアプリケーションプログラムにおける各タブに対応する前記ページウインドウを生成することが、
エンプティオーナを有する１つ以上のトップレベルウインドウとして、前記マルチタブアプリケーションプログラムにおける前記各タブに対応する前記ページウインドウを生成することをさらに含む。

マルチタブアプリケーションプログラムにおけるメッセージ対話を実行するシステムは、
１つ以上のトップレベルウインドウとして、前記マルチタブアプリケーションプログラムにおける各タグに対応する１つ以上のページウインドウを生成するように構成された、ウインドウ管理モジュールと、
前記ページウインドウに関連するメッセージ対話を実行するように構成された、メッセージ対話モジュールと、を含む。

好ましくは、前記ウインドウ管理モジュールはさらに、前記マルチタブアプリケーションプログラムのメインフレームウインドウと同じレベルに、１つ以上のトップレベルウインドウとして、前記マルチタブアプリケーションプログラムにおける前記各タブに対応する１つ以上のページウインドウを生成するように用いられる。

好ましくは、前記メッセージ対話モジュールはさらに、前記マルチタブアプリケーションプログラムのメインフレームウインドウにおいて、１つ以上のメッセージをノンブロッキングモードで前記ページウインドウに送信するように用いられる。

好ましくは、前記メッセージ対話モジュールは、
前記マルチタブアプリケーションプログラムのメインフレームウインドウと１つ以上の前記ページウインドウの間のマッピング関係を生成し、記憶するように構成されたマッピング関係記憶サブモジュールと、
前記メインフレームウインドウと１つ以上の前記ページウインドウの間のマッピング関係に基づいて、１つ以上のメッセージを１つ以上のページウインドウに送信するメインフレームウインドウによって用いられ、受信されたメッセージに対応する１つ以上の動作を実行するように前記ページウインドウをトリガするように用いられる、通信サブモジュールと、をさらに含む。

好ましくは、前記システムは、前記マルチタブアプリケーションプログラムのメインフレームウインドウの位置およびサイズと合致させるように、１つ以上の前記ページウインドウの位置およびサイズを調整するように構成された、ウインドウ調整モジュールをさらに含む。

好ましくは、前記システムは、ページウインドウがハングした場合、ユーザにプロンプトで示すように構成されたプロンプトモジュールをさらに含む。

好ましくは、前記ウインドウ管理モジュールは、前記マルチタブアプリケーションプログラムにおける新しいタブを生成する場合、トップレベルウインドウとして前記新しいタブに対応するページウインドウを生成するようにさらに構成される。

好ましくは、前記マルチタブアプリケーションプログラムは、マルチタブウェブページブラウザ、マルチタブドキュメントエディタ、またはマルチタブリーダを含む。

好ましくは、前記システムは、前記マルチタブアプリケーションプログラムにおける複数の前記タブに対応する複数の前記ページウインドウを異なるスレッドに生成するように構成された、第１の生成モジュール、
および／または、
前記マルチタブアプリケーションプログラムのメインフレームウインドウと、１つ以上の前記タブに対応する１つ以上の前記ページウインドウを異なるスレッドに生成するように構成された、第２の生成モジュール、をさらに含む。

好ましくは、前記ウインドウ管理モジュールは、エンプティオーナを有する１つ以上のトップレベルウインドウとして、前記マルチタブアプリケーションプログラムにおける各タブに対応する１つ以上のページウインドウを生成するようにさらに構成される。

コンピュータプログラム命令を含むコンピュータ読み取り可能な媒体は、前記コンピュータプログラム命令がコンピュータユニットによって実行された場合、コンピュータユニットに、
１つ以上のトップレベルウインドウとして、マルチタブアプリケーションプログラムにおける各タブに対応する１つ以上のページウインドウを生成することと、
前記ページウインドウに関連するメッセージ対話を実行することと、を指示する。

本発明の実施形態は以下の技術的効果を開示する。

本発明の実施形態によれば、トップレベルウインドウとしてマルチタブアプリケーションプログラムにおけるタブに対応するページウインドウを生成することによって、ページウインドウはもはや親ウインドウを有さなくなる。したがって、ページウインドウに対応するメッセージ対話を実行する場合、親ウインドウがシステムメッセージをページウインドウにブロッキングモードで送信する状況がなくなる。したがって、そのようなシステムメッセージを送信することによって生じるページウインドウのハングの蔓延の問題が回避されうる。１つのページウインドウがハングした場合であっても、他のページウインドウは影響を受けない。すなわち、アプリケーションプログラムの通常の実行に影響を与えることなく、他のページウインドウ上の動作は通常どおり実行されうる。

従来技術におけるマルチタブブラウザのインターフェイスの例示図である。 マルチタブアプリケーションプログラムにおいてメッセージ対話を実現する本発明の実施形態によって提供される方法のフロー図である。 従来技術におけるマルチタブブラウザのウインドウ構造の例示図である。 本発明の実施形態におけるマルチタブブラウザのウインドウ構造の例示図である。 本発明の実施形態におけるページウインドウのハングの最中のインターフェイスの例示図である。 本発明の実施形態におけるマルチタブアプリケーションプログラムにおいてメッセージ対話を実現する例示図である。

本発明の上記の目的、特徴および利点をよりよく理解するために、以下には図面および詳細な実施形態と共に、本発明の詳細な記載をさらに提供する。

図２を参照すると、本発明は、マルチタブアプリケーションプログラムにおいてメッセージ対話を実現し、以下のステップを含む方法を提供する。

Ｓ２０１：トップレベルウインドウとして、マルチタブアプリケーションプログラムにおける各タブに対応する１つ以上のページウインドウを生成する。

Ｓ２０２：トップレベルウインドウにおいてユーザメッセージ対話を実施する。すなわち、アプリケーションプログラムのメインフレームウインドウとトップレベルウインドウとしてのページウインドウの間のメッセージ対話などの、ページウインドウに関連するメッセージ対話を実行する。

理解を容易にするために、本発明の実施形態において参照される、マルチタブアプリケーションプログラムの概念と、オペレーティングシステムなどのウインドウおよびトップレベルウインドウの概念を、以下に簡単に説明する。図１を参照すると、タブに関して、従来のマルチタブウェブブラウザのインターフェイスが示される。図１においては、「遨游起始頁」「搜狐−中国．．．」および「空白頁」と名付けられた小さい長方形の箱が個々のウェブページのタブであり、各タブはウェブページウインドウに対応する。いわゆるマルチタブアプリケーションプログラムは、単独のウインドウに表示するための個々のタブに対応するページウインドウを統合し、タブがクリックされた場合に異なるページどうしを切り換える。例えば、図１に示されるウェブページブラウザは同時に複数のタブを含むことができ、したがってマルチタブウェブブラウザと呼ばれる。

本発明の実施形態において示されるマルチタブアプリケーションプログラムには、マルチラブウェブブラウザ、マルチタブドキュメントエディタ（例えばｅｘｃｅｌなど）、およびマルチタブドキュメントリーダなどが挙げられるが、これらに限られない。加えて、アプリケーションプログラムはシングルプロセスアプリケーションプログラムまたはマルチプロセスアプリケーションプログラムであってよく、個々のタブに対応するページウインドウは単一のプロセスで生成されてもよく、複数のプロセスで生成されてもよい。しかしながら、単一のプロセスで生成される場合も複数のプロセスで生成される場合も、ページウインドウはすべてハングの蔓延の問題を有する。本発明の実施形態によるそのような問題の解決方法は、マルチプロセスアプリケーションプログラムと同様にシングルプロセスアプリケーションプログラムにも応用可能である。

本発明の実施形態において記載されるように、ウインドウはシステムの表示領域を参照する。アプリケーションプログラムはウインドウを使用して、出力を表示するか、ユーザからの入力を受信する。本発明の実施形態において記載される「ウインドウ」は、Ｗｉｎｄｏｗｓにも、他の従来のウインドウベースのオペレーティングシステムにも限られないことに留意すべきである。Ｗｉｎｄｏｗｓでないオペレーティングシステムにおいてさえも、ヒューマンコンピュータ対話（ＨＣＩ）インターフェイス（例えばダイアログボックスなど）は、コンピュータインターフェイスとして提供される限り、本発明の実施形態において記載されたウインドウと見なすことができる。一方では、アプリケーションプログラムはウインドウを介してシステムディスプレイにアクセスし、他方では、アプリケーションプログラムはウインドウを使用してシステムディスプレイを他のアプリケーションプログラムと共用する。任意の所与の時刻において、ユーザ入力を受信することができるウインドウは１つのみであるため、ユーザはウインドウおよび、マウス、キーボードならびにほかの入力装置を介してウインドウを占有するアプリケーションプログラムと対話できる。

Ｗｉｎｄｏｗｓファミリーオペレーティングシステムがここで例として使用される。Ｗｉｎｄｏｗｓオペレーティングシステム（他のウインドウベースのグラフィカルオペレーティングシステム、例えばＭａｃ特有のオペレーティングシステム、ｍａｃなども含む）においては、すべてのグラフィカルインターフェイスベースのアプリケーションプログラムは少なくとも１つのウインドウを生成する必要があり、それはメインフレームウインドウと呼ばれる。このウインドウはユーザとアプリケーションプログラムの間の主要なインターフェイスである。多くのアプリケーションプログラムが、関連するタスクを完了するために、直接的に、あるいは間接的にいくつかの他のウインドウを生成してもよい。ひとたび１つのウインドウが生成されると、Ｗｉｎｄｏｗｓシステムは対応するユーザ対話メッセージをウインドウに提供することができる。Ｗｉｎｄｏｗｓシステムは、ウインドウを動かす、ウインドウのサイズを調節するなどのユーザによって要求された多くのタスクを自動的に完了することができる。Ｗｉｎｄｏｗｓ環境においては、任意の数のウインドウが生成されうる。Ｗｉｎｄｏｗｓは様々な方法で情報を表示でき、ディスプレイスクリーンの管理とウインドウの位置および表示の制御に関与し、いかなる２つのアプリケーションプログラムも同時にシステムディスプレイの同じ部分で競合することがないことを保証する。

アプリケーションプログラムウインドウは一般に、タイトルバー、メニューバー、ツールバー、境界、クライアント領域、スクロールバーおよびほかの構成要素を含む。複数のウインドウの間の関係は通常、樹枝状の接続関係、すなわち、１つのウインドウが０、１、２またはそれ以上の子ウインドウを有し、各子ウインドウは１つのみの定められた親ウインドウを有することができる。特定のウインドウが親ウインドウを有さないか、デスクトップウインドウ（ウインドウクラスが＃３２７６９であるウインドウはデスクトップウインドウと呼ばれる）である場合、その特定のウインドウはトップレベルウインドウと呼ばれる。

例としてＷｉｎｄｏｗｓオペレーティングシステムをなおも使用して、Ｗｉｎｄｏｗｓアプリケーションプログラムを実行することは、ドライブとしての外部イベントに依存することを必要とし、外部イベントを記載する情報はメッセージと呼ばれる。例えば、ユーザがキーボード上のキーを押すと、システムはキーボードが押されたというイベント（ｋｅｙｂｏａｒｄ−ｂｅｉｎｇ−ｐｒｅｓｓｅｄ ｅｖｅｎｔ）の発生を示す特定のメッセージを生成する。いわゆるイベント駆動は、Ｗｉｎｄｏｗｓアプリケーションプログラムの実行順がイベントの発生順に依存することを意味し、イベント駆動型プログラムの設計はメッセージの生成と取り扱いが中心となる。実行させると、Ｗｉｎｄｏｗｓアプリケーションプログラムは連続して、任意の可能な入力メッセージを受信し、決定を生成し、そして適切な処理を実行する。

アプリケーションプログラムによって得られる様々なメッセージは、ハードウェア装置によって生成される入力メッセージと、Ｗｉｎｄｏｗｓオペレーティングシステムからのシステムメッセージとして分類することができる。

アプリケーションプログラムは入力メッセージからの入力を受信する。例えば、マウスの移動またはキーボードが押されたことは入力メッセージを生成しうる。Ｗｉｎｄｏｗｓシステムはすべての入力装置を監視して入力メッセージをキューに配置することに関与し、ここでキューとはメッセージを一時的に記憶するシステム定義メモリブロック、いわゆるシステムメッセージキューである。Ｗｉｎｄｏｗｓシステムにおいて実行される各グラフィック装置インターフェイス（ＧＤＩ）スレッドは、それ自身のメッセージキューを有する。

ユーザがマウスを移動させるかキーボードを押すと、得られた入力メッセージがまずシステムメッセージキューに配置される。したがって、Ｗｉｎｄｏｗｓシステムはシステムメッセージキューから毎回１つの入力メッセージを取り除き、取り除かれた入力メッセージに関する宛先ウインドウを決定し、取り除かれた入力メッセージを、宛先ウインドウを生成したアプリケーションプログラムのメッセージキューに送信する。アプリケーションプログラムはアプリケーションプログラムキューによる入力を受信する。すなわち、アプリケーションプログラムはメッセージループと呼ばれる制御構造を用いてアプリケーションプログラムキューからメッセージを読み出し、読み出されたメッセージを対応するウインドウに送信する。対応するウインドウのウインドウ機能は、したがって、メッセージのチェックおよび適切な処理の実行に関与する。

システムメッセージは入力メッセージとは異なる。Ｗｉｎｄｏｗｓシステムはシステムメッセージを、システムメッセージキューおよびアプリケーションプログラムキューを介して送信するのではなく、適切なウインドウ機能に直接送信する。このようにして、Ｗｉｎｄｏｗｓシステムは特定のウインドウに影響を与えるイベントを、該特定のウインドウに直接通知する。例えば、ユーザがアプリケーションプログラムウインドウを起動させた場合、Ｗｉｎｄｏｗｓシステムは該起動させたウインドウに、対応するシステムメッセージを直接送信する。

一般に、メッセージは２つのモード、すなわち、ブロッキングモード（例えば「ＳｅｎｄＭｅｓｓａｇｅ」）およびノンブロッキングモード（例えば「ＰｏｓｔＭｅｓｓａｇｅ」「ＰｏｓｔＴｈｒｅａｄＭｅｓｓａｇｅ」「ＳｅｎｄＭｅｓｓａｇｅＣａｌｌｂａｃｋ」「ＳｅｎｄＮｏｔｉｆｙＭｅｓｓａｇｅ」および「ＳｅｎｄＭｅｓｓａｇｅＴｉｍｅｏｕｔ」など）で送信可能であることに留意すべきである。当業者は通常、「ＳｅｎｄＭｅｓｓａｇｅ」を同期メッセージ送信方法とみなし、「ＰｏｓｔＭｅｓｓａｇｅ」「ＰｏｓｔＴｈｒｅａｄＭｅｓｓａｇ」「ＳｅｎｄＭｅｓｓａｇｅＣａｌｌｂａｃｋ」「ＳｅｎｄＮｏｔｉｆｙＭｅｓｓａｇｅ」を非同期メッセージ送信方法とみなし、「ＳｅｎｄＭｅｓｓａｇｅＴｉｍｅｏｕｔ」をタイムアウト機構を備えた同期メッセージ送信方法とみなす。例えば、ウインドウＢはスレッドＡに属していない（ウインドウＢがスレッドＡに属しているかどうかは、ウインドウＢがどのスレッドにおいて生成されたかによって決まる。すなわち、ウインドウＢがスレッドＡにおいて生成された場合、ウインドウＢはスレッドＡに属するが、そうでないばあいはウインドウＢはスレッドＡに属さない）と仮定する場合、スレッドＡがメッセージをウインドウＢに送信するとき、異なるメッセージ送信モードが以下の特徴を有してもよい。

スレッドＡがメッセージＭをウインドウＢにブロッキングモードで送信する場合、スレッドＡの実行が続行される前に、スレッドＡはウインドウＢがメッセージＭの処理を完了するまで待たなくてはならない。ウインドウＢがメッセージＭを処理する場合、処理の最中に発生した無限ループまたはデッドロックなどの何らかの問題が、メッセージ処理が戻ることを阻止することがある。この時点で、ウインドウＢはハングしているとみなされ、したがってスレッドＡは実行も、他のメッセージを受信して処理することも続行できない。したがって、ウインドウＢのハングは直接スレッドＡのハングを引き起こすことがあり、その後にスレッドＡ内のすべてのウインドウがハングする。

メッセージがノンブロッキングモードで送信される場合、ウインドウＢにメッセージを送信したすぐ後にスレッドＡは戻ることができ、ウインドウＢがメッセージＢの処理を完了するまで待つ必要はない（「ＰｏｓｔＭｅｓｓａｇｅ」ならびに他の非同期方法を使用する場合は、待つ必要がない。「ＳｅｎｄＭｅｓｓａｇｅＴｉｍｅｏｕｔ」を使用する場合は、待ち時間閾値がプリセットされることができ、スレッドＡがプリセットされた閾値よりも長い期間待った場合は、スレッドＡは待つのをやめ、戻って他のメッセージを取り扱う）。したがって、ウインドウＢがハングした場合は、スレッドＡは実行を続けることができる。

上記の２つの場合において、ウインドウＢはスレッドＡに属さない。ウインドウＢがスレッドＡに属する場合、ウインドウのハングはメッセージがブロッキングモードで送信されるかノンブロッキングモードで送信されるかにかかわらず蔓延する。したがって、ウインドウＢのハングは常にスレッドＡに影響を与える。加えて、ウインドウＢは子ウインドウまたはトップレベルウインドウであることができ、ウインドウ構造は上記の性能に影響を与えない。

アプリケーションプログラムによって読み込まれた様々なメッセージの間で、入力メッセージのためのメッセージ送信モードが通常はアプリケーションプログラム（通常はノンブロッキングモードに設定される）によって決定される。これに対して、システムメッセージのための送信モードは一般にオペレーティングシステムによって決定される。例として、現在最も広く用いられているＷｉｎｄｏｗｓオペレーティングシステムを使用すると、Ｗｉｎｄｏｗｓオペレーティングシステムはシステムメッセージをブロッキングモードで送信する（通常は「ＳｅｎｄＭｅｓｓａｇｅ」を使用する）。

本発明の実施形態において提供される方法のよりよい理解のために、以下では、マルチタブブラウザにおいて一度ページがハングすると他のページも動作しなくなる理由を解析するための例として、マルチタブウェブページブラウザを使用する。

ウインドウを生成する場合、現在のマルチタブウェブページブラウザは通常、異なるタブに対応するページウインドウを同じ親ウインドウから引き継ぐ。例えば、図３は、図１と同じウェブページを閲覧するＹａｏｙｏｕブラウザのウインドウ構造を示す。

図３において、「Ｍａｘｔｈｏｎ２＿Ｖｉｅｗ」はウェブページコンテンツを表示するウインドウであり、単にページウインドウと呼ばれる。Ｍａｘｔｈｏｎ２＿Ｖｉｅｗは単にコンテナウインドウにすぎず、ウェブページコンテンツを表示するように構成された、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ＿Ｓｅｒｖｅｒ（図示せず）などの他の子ウインドウも有することに留意すべきである。３つのウェブページが現在開かれているため、３つのＭａｘｔｈｏｎ２＿Ｖｉｅｗページウインドウがウインドウ構造内にあり、これら３つのページウインドウのすべてが親ウインドウとして「Ａｆｘ：４０００００：２００８：１００１１：０：０」ウインドウを有する。

言い換えれば、各タブはウェブページに対応し、各ウェブページはウインドウのグループによって管理される（ウインドウ構造図内の「Ｍａｘｔｈｏｎ２＿Ｖｉｅｗ」の前の「＋」記号の下にある子ウインドウ（図示せず）のグループを参照）。子ウインドウのグループは親ウインドウ（すなわち「Ｍａｘｔｈｏｎ２＿Ｖｉｅｗ」）を有し、それらの親ウインドウ（すなわち「Ｍａｘｔｈｏｎ２＿Ｖｉｅｗ」）もまた親ウインドウ（すなわち上記ウインドウ構造における「Ａｆｘ：４０００００：２００８：１００１１：０：０」）を有する。

このウインドウ構造において、ユーザがタブに対応するページ上である動作を実行する場合（例えばウェブページズーム動作）、処理の流れは以下のようになる。ユーザはまずズームボタンをクリックし、このボタンを含むウインドウがメインフレームウインドウにメッセージがクリックされたことを知らせる。メインフレームウインドウが現在表示されているタブに対応するページウインドウを発見し、該ページウインドウにズーム動作を送信する。そして、ページウインドウはメッセージを読み込みズーム動作を実行する。もちろん、この期間に、Ｗｉｎｄｏｗｓオペレーティングシステムの特徴（前記したような）のために、あるシステムメッセージがウインドウの間で交換されてもよい。これらのシステムメッセージはＷｉｎｄｏｗｓオペレーティングシステムによってブロッキングモードで送信される。したがって、すべてのシステムメッセージに応答があった後にのみ、ページウインドウの動作が完了することができる。

例えば、図３に示すウインドウ構造（明確にするために、「０５Ｂ６」、「０７０Ｃ」および「０７７４」が、それぞれ「Ｗｉｎｄｏｗ００４７０５Ｂ６””Ｍａｘｔｈｏｎ２＿Ｖｉｅｗ」、「Ｗｉｎｄｏｗ００６Ｃ０７０Ｃ””Ｍａｘｔｈｏｎ２＿Ｖｉｅｗ」および「Ｗｉｎｄｏｗ００２７０７７４””Ｍａｘｔｈｏｎ２＿Ｖｉｅｗ」を示すために用いられる）において、現在示されるタブに対応するウインドウが「０５Ｂ６」でありユーザがズームボタンをクリックしたとすると、メインフレームウインドウ「Ｍａｘｔｈｏｎ２＿Ｆｒａｍ」がズーム動作メッセージを「０５Ｂ６」ページウインドウに送信するとき、「０５Ｂ６」ページウインドウの親ウインドウ「Ａｆｘ：４０００００：２００８：１００１１：０：０」は、システムメッセージをその子ウインドウのそれぞれ（例えば「０５Ｂ６」、「０７０Ｃ」および「０７７４」）にブロッキングモードで送信する必要がある。さらに、すべてのシステムメッセージが応答した後にのみ、ページウインドウ「０５Ｂ６」上のズーム動作が完了することができる。

この時点では、現在示されている「０５Ｂ６」がハングした場合、ユーザが「０７０Ｃ」上で動作したいときに、ページウインドウ「０７０Ｃ」の親ウインドウ「Ａｆｘ：４０００００：２００８：１００１１：０：０」がなおもシステムメッセージをその子ウインドウのそれぞれ（例えば「０５Ｂ６」、「０７０Ｃ」および「０７７４」）にブロッキングモードで送信する必要がある。しかしながら、「０５Ｂ６」がハングした場合、「０５Ｂ６」は、親「Ａｆｘ：４０００００：２００８：１００１１：０：０」が「０５Ｂ６」にシステムメッセージを送信した後に応答することができない。したがって、親ウインドウ「Ａｆｘ：４０００００：２００８：１００１１：０：０」がいつまでも待ち状態にあり、「０７０Ｃ」の動作は完了することができない。「０７０Ｃ」の動作を完了するために、親ウインドウ「Ａｆｘ：４０００００：２００８：１００１１：０：０」は「０７０Ｃ」を含むその子ウインドウのそれぞれにシステムメッセージを送信する必要がある。しかしながら、ハング「０５Ｂ６」は親ウインドウ「Ａｆｘ：４０００００：２００８：１００１１：０：０」に対応する必要がないため、ブロッキングモードのために、親ウインドウ「Ａｆｘ：４０００００：２００８：１００１１：０：０」はページウインドウ「０５Ｂ６」からの応答を受信するまで他の動作を実行することができず、親ウインドウ「Ａｆｘ：４０００００：２００８：１００１１：０：０」は「０７０Ｃ」上のユーザ動作を完了するためにすべての子ウインドウにシステムメッセージを送信することを完了できない。したがって、「０７０Ｃ」上のユーザ動作がいつまでも待ち状態にあり、「０７０Ｃ」はもはやシステムメッセージに応答することができない。同様に、「０７７４」へのいかなる動作も完了することができない。すなわち、ウインドウ「Ａｆｘ：４０００００：２００８：１００１１：０：０」とページウインドウ「０５Ｂ６」「０７０Ｃ」「０７７４」の間の親子関係に基づいて、ページウインドウ上の任意の動作を完了するためには、親ウインドウ「Ａｆｘ：４０００００：２００８：１００１１：０：０」がシステムメッセージをその子ウインドウのそれぞれにブロッキングモードで送信する必要がある。したがって、いかなるページウインドウのハングも、他のページウインドウが動作不能になるため、他のページウインドウに直接影響しうる。

Ｗｉｎｄｏｗｓシステム内のすべてのシステムメッセージがノンブロッキングモードで送信可能な場合、異なるウインドウが異なるスレッドに配置される限り、アプリケーションプログラムは当然ながらハングを阻止されることができる。しかし上に述べたように、実際にはそれが当てはまらない。ある周辺機器のメッセージ（例えばマウス、キーボードなど）ならびに描画メッセージ（ＷＭ＿ＰＡＩＮＴ、ＷＭ＿ＮＣＰＡＩＮＴなど）のみがノンブロッキングモードで送信される。他のシステムメッセージ（例えば、サイズ変更の告知ＷＭ＿ＳＩＺＥ、位置変更の告知ＷＭ＿ＰＯＳＣＨＡＮＧＩＮＧおよびＷＭ＿ＰＯＳＣＨＡＮＧＥＤなど）はブロッキングモードで送信される。

ウインドウＢがハングしたとすると、スレッドＡがウインドウＢにメッセージをノンブロッキングモードで送信する場合、スレッドＡの実行は影響を受けない（メッセージが時間内に処理されないことのみ）。しかし、スレッドＡがウインドウＢにシステムメッセージを送信する場合（システムメッセージは一般にブロッキングモードで送信される）、スレッドＡはウインドウＢのハングに続いてハングする。これらのシステムメッセージはＷｉｎｄｏｗｓシステム内で実装されるため、ページウインドウのハングの蔓延はサードパーティのアプリケーションプログラム（例えばブラウザなど）を変更することによっては阻止できない。

マルチタブアプリケーションプログラムにおいてユーザメッセージ対話を実行する場合、以下のシステムメッセージが通常生成されてブロッキングモードで送信されることができる。

親ウインドウは１つ以上の子ウインドウを有する。親ウインドウが焦点を有する場合（例えば、ブラウザのメインフレームウインドウが、ある動作によって現在のアクティブウインドウとなっている場合）、Ｗｉｎｄｏｗｓシステムは「ＷＭ＿ＣＨＩＬＤＡＣＴＩＶＡＴＥ」メッセージをブロッキングモードで送信する。

いくつかのオペレーティングシステム（例えばＷｉｎｄｏｗｓオペレーティングシステムなど）においては、多数のトップレベルウインドウ（Ａ、Ｂ、Ｃ．．．）が共通の「オーナ」ウインドウＯを有する状況がありうることに留意すべきである。１つのトップレベルウインドウのサイズまたは表示状態が変化した場合は、オーナウインドウＯはＷＭ＿ＰＯＳＣＨＡＮＧＩＮＧおよびＷＭ＿ＰＯＳＣＨＡＮＧＥＤメッセージを他のトップレベルウインドウ（Ｂ、Ｃ．．．）にブロッキングモードで送信する。もちろん、これらの状況は他のオペレーティングシステムには存在しないはずである。

上記の分析からわかるように、１つのウインドウのハングがブラウザ全体の動作不能につながる問題の根本的原因は、通常は、個々のタブに対応するページウインドウが共通の親ウインドウを有し、個々のページウインドウがユーザ入力メッセージに対応する場合、親ウインドウが個々のページウインドウにシステムメッセージを（ブロッキングモードで）送信することにある。すべてのシステムメッセージが正常に処理される場合にのみ、ユーザメッセージ対話は完了することができる。したがって、ページウインドウＡがハングした場合は、親ウインドウがページウインドウＡにシステムメッセージを送信するとき、ページウインドウＡは親ウインドウに応答メッセージを残すことができず、それが親ウインドウをいつまでも待ち状態にする。この時点では、動作が他のページウインドウ上で実行される必要がある場合、親ウインドウは反応することができない。したがって、他のページウインドウ上の動作が完了することができず、そのことが、アプリケーションプログラム全体が正常に実施できなくなることさえも引き起こす場合がある。

加えて、図３に示した上記例において、個々のページウインドウは「Ａｆｘ：４０００００：２００８：１００１１：０：０」の子ウインドウであり、「Ａｆｘ：４０００００：２００８：１００１１：０：０」はメインフレームウインドウの子ウインドウでもある。したがって、この例では、メインフレームウインドウと個々のページウインドウの間の関係は直接の親子関係ではない。実際には、しかしながら、当業者は、種々のマルチタブアプリケーションプログラムを設計する際の相違のために、個々のページウインドウがメインフレームウインドウの直接の子ウインドウである（すなわち、それらの間に直接の親子関係がある）状況、または、個々のページウインドウとメインフレームウインドウなどの間に複数のレベルのウインドウが存在する状況が存在してもよいことを理解している。しかし、いずれの状況かに関係なく、個々のページウインドウは親ウインドウを有し、親ウインドウは個々のページウインドウにシステムメッセージをブロッキングモードで送信する。したがって、ハングが蔓延する現象は常に存在する。

しかしながら、実際には、親ウインドウがシステムメッセージを個々のページウインドウにブロッキングモードで送信することに実用的な意義はないはずである（オペレーティングシステムはシステムメッセージを用いるかもしれないが、アプリケーションプログラムはシステムメッセージを用いないはずである。言い換えれば、Ｗｉｎｄｏｗｓシステムがこのシステムメッセージを送信しない場合でさえも、アプリケーションプログラムはなお正確に動作することができる）。個々のページウインドウがシステムメッセージを受信する場合、個々のページウインドウは他のいかなる処理もすることなく応答メッセージを戻す必要があるかもしれない。したがって、実際には、親ウインドウが個々のページウインドウにシステムメッセージを送信しなかった場合、現在表示されているページウインドウはユーザ入力メッセージをなおも取り扱うことができる。

したがって、本発明の実施形態においては、マルチタブアプリケーションプログラムにおける複数のタブに対応するページウインドウはメインフレームウインドウと同じレベルに、トップレベルウインドウとして生成される。したがって、個々のページウインドウにブロッキングモードでいかなるシステムメッセージを送信する親ウインドウも存在しない。もちろん、Ｗｉｎｄｏｗおよび他のオペレーティングシステムにおいて、個々のページウインドウはなおも共通のオーナを有してもよく、オーナが個々のページウインドウにシステムメッセージを送信してもよい。オーナウインドウが個々のページウインドウにシステムメッセージを送信することを避けるために、トップレベルウインドウのオーナはエンプティに設定される。

したがって、ウインドウ構造に関して、以前には単一のツリー構造に対応していたアプリケーションプログラムは、今や複数のツリー構造に対応する（ツリー構造の数はアプリケーションプログラムのタブの数によって決まる）。図４は、本発明の実施形態において提供されるマルチタブブラウザのウインドウ構造を示す。図示されるように、ＳＥ＿ＡｘＣｏｎｔｒｏｌは各タブに対応するページウインドウである。この構造は、タブに対応するページウインドウを、もはや親ウインドウを有さない（または親ウインドウとしてのデスクトップを有さない）ものとする。したがって、ページウインドウがユーザ入力メッセージに対応する場合、個々のページウインドウにメッセージを送信する親ウインドウはもはや存在せず、すべてのページウインドウは互いに独立している。したがって、ユーザ入力メッセージに応答する場合、特定のページウインドウがハングした場合でさえも、他のページウインドウは影響を受けない。ユーザは他のページウインドウを閲覧することを続行することができ、ハングしたページウインドウを閉じるかリロードすることができる。

したがって、本発明の実施形態において開示された方法が用いられる（トップレベルウインドウとしてページウインドウを生成する）場合、以前のメインフレームウインドウとページウインドウの間に多くの関係（直接の親子関係または複数のレベルのウインドウによって隔てられた関係）が存在するとしても、子ウインドウとしてのページウインドウにシステムメッセージを送信する親ウインドウは存在しない。このことは、オペレーティングシステムがシステムメッセージを送信する必要性によって生じるハング蔓延問題の根本的な解決法を提供しうる。

例えば、図４に示すウインドウ構造において（明確化のために、「０９Ｃ６」、「０Ａ６Ｅ」、「０９７Ｅ」が、それぞれページウインドウ「Ｗｉｎｄｏｗ ０１Ｆ６０９Ｃ６””ＳＥ＿ＡｘＣｏｎｔｒｏｌ」、「Ｗｉｎｄｏｗ ０１Ｄ５０Ａ６Ｅ””ＳＥ＿ＡｘＣｏｎｔｒｏｌ」および「Ｗｉｎｄｏｗ ０１０９０９７Ｅ””ＳＥ＿ＡｘＣｏｎｔｒｏｌ」を表すために使用される）、現在表示されているタブがページウインドウ「０９Ｃ６」に対応するとすれば、ユーザがブラウザのメインフレームウインドウをある動作の間に現在のアクティブウインドウにする場合（例えば、ユーザがブラウザのタイトルバーをマウスでクリックする）、メインフレームウインドウ「ＳＥ＿ＳｏｇｏｕＥｘｐｌｏｒｅＦｒａｍｅ」が使用されて対応するメッセージを「０９Ｃ６」ページウインドウに送信し、したがって動作は、いかなるシステムメッセージも生成されることなく、直接実行されうる。すなわち、ページウインドウ（「０９Ｃ６」、「０Ａ６Ｅ」、「０９７Ｅ」）が親ウインドウを有さず、これらのページウインドウのオーナもまたエンプティに設定されることができ、ブラウザのメインフレームウインドウが属するスレッドも同様に、ページウインドウにいかなるシステムメッセージも送信しない。

この時点で、現在表示されている「０９Ｃ６」がハングした場合、「０９Ｃ６」「０Ａ６Ｅ」および「０９７Ｅ」に共通の、現在表示されているページウインドウ上の動作の完了を容易にするためにこれらのページウインドウにシステムメッセージをブロッキングモードで送信する必要がある親ウインドウがないので、「０９Ｃ６」が親ウインドウに応答することができないために他のシステムメッセージを処理することができなくなる「０９Ｃ６」「０Ａ６Ｅ」および「０９７Ｅ」に共通の親ウインドウがない。したがって、ユーザが「０７０Ｃ」上で動作を実行する必要がある場合、メインフレームウインドウ「ＳＥ＿ＳｏｇｏｕＥｘｐｌｏｒｅＦｒａｍｅ」のみが「０７０Ｃ」に入力メッセージを送信する必要があり、「０７０Ｃ」上の動作を完了することができる。ページウインドウ上の動作を完了するために子ウインドウとしてのページウインドウにブロッキングモードでシステムメッセージを送信する親ウインドウに関与することがない。同様に、「０７７４」上の動作もまた完了することができる。したがって、本発明の実施形態にしたがって開示された技術的解決法によれば、ページウインドウのハングはもはや蔓延せず、アプリケーションプログラム全体が影響を受けることはない。

本発明の実施形態によれば、様々な入力メッセージ対話がノンブロッキングモードまたはブロッキングモードのいずれかで実行されることができることに留意すべきである。もちろん、ノンブロッキングモードが用いられる場合、メインフレームウインドウがメッセージをページウインドウに送信する場合、メインフレームウインドウはページウインドウがメッセージの処理を完了することを待つことなく、他のページウインドウからのメッセージを処理するために戻る。したがって、結果はより良好になる。当業者は、メインフレームウインドウによってメッセージをページウインドウに送信するためにいかなるモードが用いられるか、あるいはどのようなメッセージを生成すべきか、などをマルチタブアプリケーションプログラム自身が制御することができることを理解する。言い換えれば、このことはサードパーティのアプリケーションプログラム（例えばブラウザ）を改良することによって行われうる。しかしながら、上で述べた状況において、子ウインドウにシステムメッセージをブロッキングモードで送信する親ウインドウ（従来技術のページウインドウ）はサードパーティアプリケーションプログラム（ブラウザ）によってではなく、Ｗｉｎｄｏｗｓオペレーティングシステムによって制御される。したがって、システムメッセージを送信するためのモードは、サードパーティアプリケーションプログラムを変更することによって変更することはできず、それがページウインドウのハングの蔓延の問題を解決するための最も難しい部分となる。本発明の実施形態は異なる手法を提供する。ページウインドウを子ウインドウの本来の形態からトップレベルウインドウに変更することによって、ページウインドウはもはや親ウインドウを有さなくなる。したがって、ある親ウインドウが個々のページウインドウにシステムメッセージを送信することをＷｉｎｄｏｗｓオペレーティングシステムが必要とする状態が、もはや存在せず、それがページウインドウのハングの蔓延の問題を最終的に解決する。

上に述べたように、２つ以上のウインドウが同じスレッドに属する場合は、ブロッキングモードとノンブロッキングモードのいずれもハング蔓延を引き起こすことがある。したがって、本発明の実施形態において、ハングが蔓延することを阻止するより望ましい結果を達成するために、異なるウインドウは異なるスレッドに属するようにされてよく（例えば、異なるページウインドウは異なるスレッドに属し、および／またはメインフレームウインドウとページウインドウは異なるスレッドに属する）、ハングの蔓延の発生をさらに減少させる。もちろん、いくつかのマルチタブアプリケーションプログラムはそれ自身がマルチスレッドである。すなわち、異なるページウインドウおよびメインフレームウインドウはすでに異なるスレッドにより生成されている。したがって、これらのマルチタブアプリケーションプログラムはもはやスレッド関連の変更を必要としない。

加えて、特定のページウインドウがハングしていることが判定された場合、ユーザにプロンプトで示すことができる（ページウインドウのハングの発生をユーザに告知し、ユーザにページウインドウを閉じるかリロードするように気づかせる。図５を参照）。したがって、本発明の実施形態は効率的にユーザエクスペリエンスを向上させる。

ページウインドウがハングしているかどうかをどのように判定するかに関して、いくつかの代替の方法がそのような検査のために用いられうる。例えば、一定の時間の間（例えば５秒間）、ページウインドウが該ページウインドウに送られたいかなるメッセージも処理しない場合は、該ページウインドウはハングの可能性があるとみなす、などである。実際には、ページウインドウがハングしたかどうかを正確に検出することは不可能かもしれず（Ｗｉｎｄｏｗｓシステム自身でさえもこれを達成できない）、したがって、ある誤った検出が発生するかもしれないことに留意すべきである。

メインフレームウインドウとページウインドウの間のメッセージ対話を実施することに関して、メインフレームウインドウと個別のタブに対応するページウインドウの間に、あるマッピング関係が存在することに留意すべきである。ユーザとのメッセージ対話を完了させるために、メインフレームウインドウとページウインドウの間の通信が、このマッピング関係に基づいて達成される。Ｙａｏｙｏｕブラウザのようなブラウザのウインドウなどの従来のウインドウ構造において、Ｗｉｎｄｏｗｓシステムは自動的にそのようなマッピング関係を生成することができる。メインフレームウインドウはページウインドウを得て該ページウインドウにメッセージを送信するために、システム関数（例えばＧｅｔＷｉｎｄｏｗ（ＣＨＩＬＤ））を使用することのみが必要である。

しかしながら、本発明の実施形態において、この従来のウインドウ構造は壊され、Ｗｉｎｄｏｗｓシステムはメインフレームウインドウとページウインドウの間のマッピング関係を自動的に生成することができない可能性がある。したがって、ページウインドウを得るために呼び出される関数が存在しない。上記状況において、メインフレームウインドウとページウインドウの間の通常の通信を実施するために、以下の方法が本発明の実施形態によって用いられうる。トップレベルウインドウとしての個々のタブに対応するページウインドウを生成する場合、メインフレームウインドウとページウインドウの間のマッピング関係もまた生成され、そのようなマッピング関係が記憶されうる。したがって、メインフレームウインドウがメッセージをユーザから受信した後、メインフレームウインドウは記憶前のマッピング関係に基づいて対応するページウインドウを発見し、メッセージをページウインドウに送信しうる。メッセージはノンブロッキングモードで送信されうる。さらに、ページウインドウは受信されたメッセージに応じて対応する動作を実行する。そのような動作はズーム動作、切り換え動作、またはルックアップ動作などを含むことができる。もちろん、将来において、Ｗｉｎｄｏｗｓシステムまたは他のオペレーティングシステムが、本発明の実施形態に記載のウインドウ構造を用いて、メインフレームウインドウとページウインドウの間のマッピング関係を自動的に生成することが可能になる可能性はある。

本発明の実施形態において、タブに対応するページウインドウは、実際の必要性に応じていつでもトップレベルウインドウとして生成またはつくられることができる。好ましい方法は、新しいタブを生成するとき、生成されたタブに対応するページウインドウをトップレベルウインドウとして生成することである。さらに、マルチタブブラウザにおいて、新しいタブを生成することは２つの手法を含んでもよい。１つはユーザがタブバーをダブルクリックしたときに新しいタブを生成し該タブに対応するページウインドウが空白である。他方は、新しいタブに対応するページウインドウにおいて、通常は現在示されているページ内のリンクをクリックすることによって、あるウェブページが開かれるときにブラウザによって新しいタブが自動的に開かれる。この手法はマルチタブドキュメントエディタにおいてより有意義である。例えば「ｅｘｃｅｌ」において、ページウインドウのハングはドキュメント編集処理の最中にのみ発生しうるのではなく、ｅｘｃｅｌドキュメントを開くときにも発生しうる。ｅｘｃｅｌドキュメントが開かれたとき、タブに対応するページウインドウがハングしてタブに対応するページウインドウがトップレベルウインドウとして生成されない場合、ハングしていないだろう他のページウインドウのデータをチェックすることができなくなるだろう。したがって、新しいタブを生成するときにトップレベルウインドウとして対応するページウインドウを生成することは、この状況が発生することを阻止することができる。

本発明の実施形態によって提供される方法においては、メインフレームウインドウおよびタブに対応するページウインドウが互いに独立していることに留意すべきである。これは、従来の構成において、タブに対応するページウインドウがメインフレームウインドウのある子ウインドウという、子ウインドウであることとは異なる。必要な配置なしに、メインフレームウインドウおよびページウインドウのサイズおよび位置は任意であってよい。しかしながら、ユーザがよりよい視覚的効果を得ることを可能にするために、タブに対応するページウインドウの位置およびサイズはメインフレームウインドウの位置およびサイズと適切に合致するように調整されてもよい。言い換えれば、最後にユーザの前に示されるブラウザインターフェイスは、Ｙａｏｙｏｕならびに他のブラウザのインターフェイスと異ならなくてもよいかもしれない。しかしながら、実際にはこのブラウザインターフェイスは単一のエンティティではなく、互いに接続された複数のエンティティである。本発明の実施形態によってユーザに提供されるそのようなインターフェイスは「非同期ユーザインターフェイス（ＵＩ）」と呼ばれる。このユーザインターフェイスは、１つのタブページウインドウのハングがブラウザフレームまたはほかのタブページウインドウの動作不能を引き起こす状況が発生することを阻止することができる。

上記方法の全部または一部が、対応するハードウェアに命令するコンピュータプログラムによって達成されることができることを、当業者は理解することができる。コンピュータプログラムはコンピュータ読み取り可能な記憶媒体上に記憶されることができる。コンピュータプログラムは、実行された際に、以下のステップを含む。トップレベルウインドウとして、マルチタブアプリケーションプログラムにおいてタブに対応するページウインドウを生成し、該マルチタブアプリケーションプログラムにおいてメッセージ対話を実行する。記載の記憶装置は、例えば、ＲＯＭ／ＲＡＭ、ディスク、およびＣＤ−ＲＯＭなどであることができる。

本発明の実施形態において提供されるマルチタブアプリケーションプログラムにおいてメッセージ対話を実施する方法に対応して、マルチタブアプリケーションプログラムにおけるメッセージ対話を実行するシステムもまた、本発明の実施形態において提供される。図６を参照すると、システムは以下を含む。

ウインドウ管理モジュールＵ６０１は、トップレベルウインドウとして、マルチタブアプリケーションプログラムにおいてタブに対応するページウインドウを生成するように用いられる。前記方法によれば、マルチタブアプリケーションプログラムのメインフレームウインドウもまたトップレベルウインドウである。したがって、ページウインドウがトップレベルウインドウとして生成された後、ページウインドウとメインフレームウインドウは同じレベルにあり、すべてトップレベルウインドウである。

メッセージ対話モジュールＵ６０２は、トップレベルウインドウの間のユーザメッセージ対話を実行するように用いられる。ユーザメッセージ対話とはすなわち、ページウインドウに関連するメッセージ対話、例えばアプリケーションプログラムのメインフレームウインドウと、今はトップレベルウインドウであるページウインドウの間のメッセージ対話などである。

さらに、ウインドウ管理モジュールＵ６０１はマルチタブアプリケーションプログラムにおけるタブに対応するページウインドウをトップレベルウインドウとして生成し、マルチタブアプリケーションプログラムにおけるメッセージ対話を実行する。タブに対応するページウインドウは親ウインドウを有さないようにすることもできる。したがって、メッセージに応答する場合、ページウインドウにシステムメッセージをブロッキングモードで送信する親ウインドウは存在しない。したがって、あるページウインドウがハングした場合でさえも、他のページウインドウは影響を受けず、ユーザエクスペリエンスは向上する。

また、Ｗｉｎｄｏｗｓおよび他のオペレーティングシステムにおいて、トップレベルウインドウのオーナウインドウがページウインドウにメッセージを送信することを阻止するために、ウインドウ管理モジュールＵ６０１は、エンプティオーナを有するトップレベルウインドウとして、マルチタブアプリケーションプログラムにおいてタブに対応するページウインドウを生成することができる。非Ｗｉｎｄｏｗｓオペレーティングシステムにおいては、エンプティオーナ問題には関与しなくてよいことに留意すべきである。トップレベルウインドウとして、タブに対応するページウインドウを生成する必要があるだけであり、ユーザがあるページウインドウを動作したとき、いかなる親ウインドウもその子ウインドウ、すなわちページウインドウにシステムメッセージをブロッキングモードで送信する必要がなくなる、という目標が達成されうる。さらに、ハングの蔓延の発生の可能性を減少させるという目標もまた達成されうる。

上記の方法によれば、ハングの蔓延の発生をさらに減少させるために、メッセージ対話モジュールＵ６０２が、ノンブロッキングモードを使用してページウインドウにメッセージを送信するマルチタブアプリケーションプログラムのメインフレームウインドウにおいて、特に使用されてもよい。

本発明の実施形態によって生成されるウインドウ構造の下でメッセージに応答する処理の最中に、メインフレームウインドウはタブに対応するページウインドウにメッセージを送信し、ページウインドウは対応する動作を実行することができる。このことはメインフレームウインドウとページウインドウの間のマッピング関係を必要とする。しかしながら、ウインドウ構造は従来のウインドウ構造とは異なる上記の方法によって生成される。オペレーティングシステムはメインフレームウインドウとページウインドウの間のマッピング関係を自動的に生成することが不可能である。したがって、トップレベルウインドウを生成する場合、メインフレームウインドウとページウインドウの間のマッピング関係もまた生成されて記憶される。したがって、メッセージ対話モジュールＵ６０２は以下のサブモジュールを有してもよい。

マルチタブアプリケーションプログラムのメインフレームウインドウとページウインドウの間のマッピング関係を生成して記憶するように使用される、記憶サブモジュールＵ６０２１。

特定のタブに対応するトップレベルページウインドウにメッセージを送信するようにメインフレームウインドウをトリガし、受信されたメッセージに対応する特定の動作を実行するようにトップレベルページウインドウをトリガするように用いられる、通信サブモジュールＵ６０２２。最後に示されたインターフェイスの見え方をユーザによって用いられてきた見え方にいっそう一致させるために、システムは以下を有してもよい。

ページウインドウの位置およびサイズをメインフレームウインドウの位置およびサイズに合致させるように、ページウインドウの位置およびサイズを調整するように用いられる、ウインドウ調整モジュールＵ６０３。

加えて、システムは以下を有してもよい。

あるタブに対応するページウインドウがハングした場合、ユーザにページウインドウを閉じるかリロードすることを促すことを含む、ある告知情報をユーザにプロンプトで示すように用いられる、プロンプトモジュールＵ６０４。

本発明の好ましい形態において、新しいタブが生成された場合、例えば、新しい空白のページを生成するか新しいウインドウ内にページを開く場合、新しいタブに対応するページウインドウはトップレベルウインドウとして生成される。この手法はマルチタブドキュメントエディタにおいて、ドキュメントを開く過程の最中に１つのページのハングによってドキュメント全体が開けなくなる状況を回避するために、特に有利である。もちろん、実際の必要に応じていつでも、例えば多数のページウインドウが開かれている場合にトップレベルウインドウを生成する必要に応じて、タブに対応するページウインドウがトップレベルウインドウとして生成されうる。

上記の方法に応じて、ハングの蔓延の発生をさらに減少させるために、システムは以下を含んでもよい。

異なるスレッドにおいてマルチタブアプリケーションプログラムにおける異なるタブに対応するページウインドウを生成するように用いられる、第１の生成モジュール。ウインドウがスレッドに生成される場合、該ウインドウは該スレッドに属するため、このマルチスレッド生成モジュールは、異なるスレッドに属するマルチタブアプリケーションプログラムにおける異なるタブに対応するページウインドウを設けるように用いられてよい。

加えて、特定のメッセージ対話の最中、マルチタブアプリケーションプログラムのメインフレームウインドウは、トップレベルウインドウとして個々のページウインドウにメッセージを送信する必要がある可能性がある。上記方法において記載されたように、メインフレームウインドウおよびページウインドウが同じスレッドに属する場合、ブロッキングモードまたはノンブロッキングモードのいずれがメッセージを送信するように用いられるかにかかわらず、メインフレームウインドウとページウインドウの間のハングの蔓延はなお発生するかもしれない。したがって、好ましくは、システムは以下を含んでもよい。

メインフレームウインドウと、異なるスレッドにおける１つ以上のタブに対応する１つ以上のページウインドウと、を生成する第２の生成モジュール。すなわち、マルチタブアプリケーションプログラムのメインフレームウインドウと各ページウインドウは異なるスレッドに属する。したがって、これらの２つのウインドウが同じスレッドに属することはないため、メインフレームウインドウがページウインドウにメッセージを送信する必要がある場合、メッセージがノンブロッキングモードで送信される限り、ハングの蔓延の発生は起こらない。

上記の詳細な説明は、本発明によって提供されるマルチタブアプリケーションプログラムにおけるメッセージ対話を実行する方法および装置を記載する。個別の例は本発明の原則および実装を記載するように用いられる。しかしながら、例および実施形態は本発明の方法および精神の理解に役立たせるためのみに用いられる。また、当業者のために、特別の実装および応用の範囲が本発明の原則に基づいて変更されてもよい。要するに、本明細書の内容は本発明のいかなる限定として解釈されるべきでもない。

本出願は、発明の名称が「マルチタブアプリケーションプログラムにおけるメッセージ対話を実現する方法およびシステム」である、中国特許庁に２００９年１月２３日に出願された中国特許出願第２００９１００７７８６９．５号の優先権を主張し、その内容の全体が本明細書に参照によって組み込まれる。

好ましくは、前記マルチタブアプリケーションプログラムは、マルチタブウェブページブラウザ、マルチタブドキュメントエディタ、およびマルチタブリーダのうち１つ以上を含む。

好ましくは、前記マルチタブアプリケーションプログラムは、マルチタブウェブページブラウザ、マルチタブドキュメントエディタ、およびマルチタブリーダのうち１つ以上を含む。

Claims (22)

1. １つ以上のトップレベルウインドウとして、マルチタブアプリケーションプログラムにおける各タブに対応する１つ以上のページウインドウを生成することと、
   １つ以上の前記ページウインドウに関連するメッセージ対話を実行することと、を含む、
   マルチタブアプリケーションプログラムにおけるメッセージ対話を実行する方法。
2. １つ以上のトップレベルウインドウとして、マルチタブアプリケーションプログラムにおける各タブに対応する１つ以上のページウインドウを生成することが、
   前記マルチタブアプリケーションプログラムのメインフレームウインドウと同じレベルに、１つ以上のトップレベルウインドウとして、マルチタブアプリケーションプログラムにおける各タブに対応する１つ以上の前記ページウインドウを生成することをさらに含む、
   請求項１に記載の方法。
3. 前記ページウインドウに関連する前記メッセージ対話を実行することが、
   前記マルチタブアプリケーションプログラムのメインフレームウインドウによって、１つ以上のメッセージをノンブロッキングモードで１つ以上の前記ページウインドウに送信することを含む、
   請求項１に記載の方法。
4. 前記ノンブロッキングモードは、
   タイムアウトメカニズムと共に、非同期メッセージ送信モードまたは同期メッセージ送信方法を含む、
   請求項３に記載の方法。
5. 前記ページウインドウに関連する前記メッセージ対話を実行することが、
   前記マルチタブアプリケーションプログラムのメインフレームウインドウと１つ以上の前記ページウインドウの間にマッピング関係を生成し、記憶することと、
   前記メインフレームウインドウによって、前記メインフレームウインドウと１つ以上の前記ページウインドウの間の前記マッピング関係に基づいて、１つ以上のメッセージを前記ページウインドウに送信することと、
   受信されたメッセージに対応する１つ以上の動作を実行するように、１つ以上の前記ページウインドウをトリガすることと、を含む、
   請求項１に記載の方法。
6. 前記マルチタブアプリケーションプログラムのメインフレームウインドウの位置およびサイズと合致させるように、前記ページウインドウの位置およびサイズを調整することをさらに含む、
   請求項１から５のいずれか一項に記載の方法。
7. タブに対応するページウインドウのハングを判定した場合、ユーザにプロンプトで示すことをさらに含む、
   請求項１から５のいずれか一項に記載の方法。
8. １つ以上のトップレベルウインドウとして、前記マルチタブアプリケーションプログラムにおける各タブに対応する１つ以上のページウインドウを生成することが、
   前記マルチタブアプリケーションプログラムにおける新しいタブを生成する場合、トップレベルウインドウとして前記新しいタブに対応するページウインドウを生成することをさらに含む、
   請求項１から５のいずれか一項に記載の方法。
9. 前記マルチタブアプリケーションプログラムは、マルチタブウェブページブラウザ、マルチタブドキュメントエディタ、またはマルチタブリーダを含む、請求項１から５のいずれか一項に記載の方法。
10. 前記マルチタブアプリケーションプログラムにおける複数の前記タブに対応する複数の前記ページウインドウが、異なるスレッドに属し、
    および／または、
    前記マルチタブアプリケーションプログラムのメインフレームウインドウと、複数の前記タブに対応する１つ以上の前記ページウインドウが、異なるスレッドに属する、
    請求項１から５のいずれか一項に記載の方法。
11. トップレベルウインドウとして、前記マルチタブアプリケーションプログラムにおける各タブに対応する１つ以上の前記ページウインドウを生成することが、
    エンプティオーナを有する１つ以上のトップレベルウインドウとして、前記マルチタブアプリケーションプログラムにおける前記各タブに対応する１つ以上の前記ページウインドウを生成することをさらに含む、
    請求項１から５のいずれか一項に記載の方法。
12. １つ以上のトップレベルウインドウとして、マルチタブアプリケーションプログラムにおける各タグに対応する１つ以上のページウインドウを生成するように構成された、ウインドウ管理モジュールと、
    前記ページウインドウに関連するメッセージ対話を実行するように構成された、メッセージ対話モジュールと、を含む、
    マルチタブアプリケーションプログラムにおけるメッセージ対話を実行するシステム。
13. 前記ウインドウ管理モジュールはさらに、前記マルチタブアプリケーションプログラムのメインフレームウインドウと同じレベルに、１つ以上のトップレベルウインドウとして、前記マルチタブアプリケーションプログラムにおける前記各タブに対応する１つ以上のページウインドウを生成するように用いられる、請求項１２に記載のシステム。
14. 前記メッセージ対話モジュールはさらに、前記マルチタブアプリケーションプログラムのメインフレームウインドウにおいて、１つ以上のメッセージをノンブロッキングモードで前記ページウインドウに送信するように用いられる、請求項１２に記載のシステム。
15. 前記メッセージ対話モジュールは、
    前記マルチタブアプリケーションプログラムのメインフレームウインドウと１つ以上の前記ページウインドウの間のマッピング関係を生成し、記憶するように構成されたマッピング関係記憶サブモジュールと、
    前記メインフレームウインドウと１つ以上の前記ページウインドウの間のマッピング関係に基づいて、１つ以上のメッセージを１つ以上のページウインドウに送信するメインフレームウインドウによって構成され、受信されたメッセージに対応する１つ以上の動作を実行するように１つ以上の前記ページウインドウをトリガするように用いられる、通信サブモジュールと、をさらに含む、
    請求項１２に記載のシステム。
16. 前記マルチタブアプリケーションプログラムのメインフレームウインドウの位置およびサイズと合致させるように、１つ以上の前記ページウインドウの位置およびサイズを調整するように構成された、ウインドウ調整モジュールをさらに含む、
    請求項１２から１５のいずれか一項に記載のシステム。
17. ページウインドウがハングした場合、ユーザにプロンプトで示すように構成されたプロンプトモジュールをさらに含む、
    請求項１２から１５のいずれか一項に記載のシステム。
18. 前記ウインドウ管理モジュールは、前記マルチタブアプリケーションプログラムにおける新しいタブを生成する場合、トップレベルウインドウとして前記新しいタブに対応するページウインドウを生成するようにさらに構成される、請求項１２から１５のいずれか一項に記載のシステム。
19. 前記マルチタブアプリケーションプログラムは、マルチタブウェブページブラウザ、マルチタブドキュメントエディタ、またはマルチタブリーダを含む、請求項１２から１５のいずれか一項に記載のシステム。
20. 前記マルチタブアプリケーションプログラムにおける複数の前記タブに対応する複数の前記ページウインドウを異なるスレッドに生成するように構成された、第１の生成モジュール、
    および／または、
    前記マルチタブアプリケーションプログラムのメインフレームウインドウと、１つ以上の前記タブに対応する１つ以上の前記ページウインドウを異なるスレッドに生成するように構成された、第２の生成モジュール、をさらに含む、
    請求項１２から１５のいずれか一項に記載のシステム。
21. 前記ウインドウ管理モジュールは、エンプティオーナを有する１つ以上のトップレベルウインドウとして、前記マルチタブアプリケーションプログラムにおける各タブに対応する１つ以上のページウインドウを生成するようにさらに構成される、請求項１２から１５のいずれか一項に記載のシステム。
22. コンピュータプログラム命令がコンピュータユニットによって実行された場合、コンピュータユニットに、
    １つ以上のトップレベルウインドウとして、マルチタブアプリケーションプログラムにおける各タブに対応する１つ以上のページウインドウを生成することと、
    前記ページウインドウに関連するメッセージ対話を実行することと、を指示する、
    コンピュータプログラム命令を含むコンピュータ読み取り可能な媒体。

Images