(57)【要約】【課題】場面に応じた処理を柔軟に対応するとともに、デフォルトの処理をまとめることも可能にし、アプリケーションの設計工数を大幅に削減することを可能にすることである。【解決手段】アプリケーションなどを駆動するイベントドリブンなシステムにおけるイベント処理方法であって、メインイベントハンドラとサブイベントハンドラを設け、あるイベントが発生した場合にまずサブイベントハンドラにイベントを通知し、そこで処理されなかったイベントをメインイベントハンドラに転送することを特徴とする。【選択図】図１
2006155302.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションなどを駆動するイベントドリブンなシステムにおけるイベント処理方法であって、
メインイベントハンドラとサブイベントハンドラを設け、
或るイベントが発生した場合に先ずサブイベントハンドラにイベントを通知し、
そこで処理されなかったイベントをメインイベントハンドラに転送することを特徴とするイベント処理方法。
【請求項２】
メインイベントハンドラが主にアプリ全体に関わるイベントを処理し、
サブイベントハンドラが主に場面場面に応じたインタラクティブなイベントを処理することを特徴とする請求項１記載のイベント処理方法。
【請求項３】
サブイベントハンドラで処理されなかったイベントを、メインイベントハンドラに転送するか否かをチェックする手段を設け、転送すると判断した時だけメインイベントハンドラに転送する請求項１又は２記載のイベント処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーション等を駆動するイベントドリブンなシステムにおけるイベント処理方法に関し、特にコールバックハンドラによるイベントハンドラを使用した処理方法に関するものである。
【背景技術】
【０００２】
近年、様々な製品分野でＧＵＩ機能を備えたものが登場してきている。デジタル複写機、デジタルカメラ、マルチファンクションプリンタ等が例として挙げられる。これら組み込み機器の分野で扱う機能の増大に伴い、画面遷移や画面制御のためにシンプルなウインドウシステムの必要性が増大してきている。又、十分な表示機能を持たない製品でも、表示がないだけで、各機能間やシステムからののイベントを同様のハンドラで処理した方が設計が容易になる場合が多かった。このように、組み込み機器用途向けのアプリのイベント処理方法は多機能製品には必要不可欠となってきている。
【０００３】
Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（ＴＭ）がハンドラコールバックによるイベントドリブンな代表的な例である。Ｗｉｎｄｏｗｓの構造に関する書物は非常にたくさん存在するが、例えば、非特許文献１等に基本的な部分の説明がある。
【０００４】
Ｗｉｎｄｏｗｓの場合、ハンドラは大きく分けてウインドウハンドラ、ダイアログハンドラの２種類のコールバックハンドラがあり、それぞれに専用のイベントメッセージと共通のイベントメッセージとがあり、専用のイベントメッセージは例えば、ウインドウの消去を示すＷＭ_DESTROYメッセージはウインドウハンドラに対してのみ送付され、ダイアログハンドラに対しては決して送付されることはない。
【０００５】
ウインドウハンドラでもチャイルドウインドウの場合はWM_DESTROYメッセージは特に処理する必要がなく、デフォルト処理にまわせば良いが、メインウインドウハンドラはWM_DESTROYメッセージが送付された時は、Ｐｏｓｔ  Ｑｕｉｔ  Ｍｅｓｓａｇｅ（ＴＭ）でアプリを終了する必要がある。
【０００６】
一方のダイアログハンドラは、Ｗｉｎｄｏｗｓの内部に含まれるウインドウハンドラ経由で呼ばれる。このため、送付されるメッセージも多少異なり、先の例のWM_DESTROYメッセージは送付されない。ダイアログハンドラでは、設計者は主にコントロールの制御を設計すれば良いようにできている。又、アプリ設計者は他のアプリの存在を意識することなく、メモリ等のリソースも必要なだけ使用できる。
一方で、組み込み機器の場合、Ｗｉｎｄｏｗｓアプリケーションとは違い、実行中の機能が相互に影響し合う場合が多い。例えば、Ｗｉｎｄｏｗｓアプリケーションであればアプリの切換えはウインドウを切り替えるだけで済んでしまうが、組み込み機器の場合１つのリソースを共有する機能間では、或る機能が使用中であれば他の機能には制御を移さないようにすることを容易にする仕組みも必要である。
【０００７】
【非特許文献１】「プログラミングＷｉｎｄｏｗｓ  Ｖｏｌｕｍｅ１」（１９８９ Ｃｈａｒｌｅｓ Ｐｅｔｚｏｌｄ著 エー・ピー・ラボ訳）
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、或るアプリケーション全体を管理するメインのイベントハンドラと、そのアプリケーションの各場面場面の操作を提供するダイアログのようなサブハンドラがあった場合、Ｗｉｎｄｏｗｓ等の従来技術では、或るイベントが発生した場合に呼び出されるハンドラは一意に決定される。例えば、メインハンドラに送付されるべきイベントは、通常はサブハンドラに送付されることはない。このようなことを実現しようとすると、メインハンドラはどのサブハンドラが動作中かを常に記憶しておき、自分が受けたイベントをサブハンドラに転送する処理を持つか、或いは動作中のサブハンドラに応じた処理を一々個別に設計する必要があった。即ち、場面に応じた細かな例外処理の設計が困難なことがあった。
【０００９】
本発明は、上記問題に鑑みてなされたもので、その目的とする処は、場面に応じた処理を柔軟に対応するとともに、デフォルトの処理をまとめることも可能にし、アプリケーションの設計工数を大幅に削減することを可能にすることである。
【課題を解決するための手段】
【００１０】
上記問題を解決するため、本発明では、アプリケーションなどを駆動するイベントドリブンなシステムにおけるイベント処理方法において、メインイベントハンドラとサブイベントハンドラを設け、或るイベントが発生した場合に先ずサブイベントハンドラにイベントを通知し、そこで処理されなかったイベントをメインイベントハンドラに転送することを特徴とする。
【００１１】
更に、メインイベントハンドラが主にアプリ全体に関わるイベントを処理し、サブイベントハンドラが主に場面場面に応じたインタラクティブなイベントを処理することを特徴とする。
【００１２】
更に、サブイベントハンドラで処理されなかったイベントを、メインイベントハンドラに転送するか否かをチェックする手段を設け、転送すると判断した時だけメインイベントハンドラに転送することを特徴とする。
【発明の効果】
【００１３】
本発明によれば、アプリケーションなどを駆動するイベントドリブンなシステムにおけるイベント処理方法において、メインイベントハンドラとサブイベントハンドラを設け、或るイベントが発生した場合に先ずサブイベントハンドラにイベントを通知し、そこで処理されなかったイベントをメインイベントハンドラに転送することにより、場面に応じた処理を柔軟に対応するとともに、デフォルトの処理をまとめることも可能となり、アプリケーションの設計工数を大幅に削減することを可能とした。
【発明を実施するための最良の形態】
【００１４】
＜実施の形態１＞
図１は本発明に則したイベント処理システムを搭載したマルチファンクションプリンタの構成を示すブロック図である。
【００１５】
１−１は、ＣＰＵであり、以降の説明で示すフローチャートの制御や各種演算を行う。１−２は、ＲＡＭであり、描画のためのイメージや各種処理のワークメモリとして使用する。１−３は、ＲＯＭであり、プリンタの制御プログラムや各種テーブル等が保持されている。１−４は、Ｉ／Ｆであり、ＰＣ等のホストと接続するためのＵＳＢデバイスＩ／Ｆや、ＰｉｃｔＢｒｉｄｇｅ仕様のデジタルカメラと接続するためのＵＳＢホストＩ／Ｆである。１−５は、キーコントローラ及びのキーで、キー（ボタン）の押下情報等を管理する。１−６は、表示部で、各種情報を表示するのに使用する。１−７は、プリントエンジンで、インクヘッドやモーターを制御して印字動作を行う。１−８は、スキャナエンジンで、スキャナヘッド等を制御して原稿第二セットされた原稿を読み込む。１−９は、カードスロットで、コンパクトフラッシュやＳＤカード等のメモリメディアを挿入して読み込むために使用される。最後に、１−１０は、システムバスであり、ＣＰＵや他のコントローラ間のデータの通り道である。
【００１６】
図２はマルチファンクションプリンターに搭載されているアプリの一部である。コピーアプリは、スキャナで原稿を読み取りつつ、プリンタで読み取った画像イメージを出力する。フォトプリントは、カードスロットに挿入されたメモリカード内の写真をユーザーが選択してプリンタで印刷する。この他にもＰｉｃｔ  Ｂｒｉｄｇｅカメラを接続してカメラから印刷を行うアプリや、ＰＣ等のホストから印刷データを受信して印刷を行うアプリが搭載されているが、ここでは説明を省略する。
【００１７】
図３は図１で示したマルチファンクションプリンタの一実施形態における操作部周りの外観図である。
【００１８】
液晶パネルと各種キーが配置されている。 キーのうち、「コピー」「フォトプリント」の２つは個別アプリケーション専用キーでシステムでは処理されずにアプリケーションが直接ハンドリングする。それ以外のキーは汎用キーイベントとして、システムから現在操作中のアプリケーションに通知される。詳細は以後の実施例で解説する。
【００１９】
図４は、図３の液晶パネルに表示されるアプリケーション画面の一例である。
【００２０】
それぞれの画面にはイベントハンドラ（ＭＰ−ＸＸ、Ｐ−ＸＸ：ＸＸはハンドラを識別するためのユニークな値  以後同じ）が関連付けられていることを示している。ＭＰ−ＸＸは、メインイベントハンドラであることを示し、１つのアプリケーションに１つだけ存在し、又、アプリケーションが動作している間は必ず起動されているものとする。Ｐ−ＸＸは、サブイベントハンドラでアプリケーションの場面場面に応じて、対応する画面とともにアクティブになったりインアクティブになったりすることがある。
【００２１】
図４では、それぞれのイベントハンドラで処理するイベントの一部を示している。コピーアプリの場合、Ｗ−Ａ１がメイン画面でＭＰ−Ａ１がメインイベントハンドラである。コピーアプリではこの他にシステム共通画面のＷ−Ｃ１やＷ−Ｃ２及が使用される。コピーアプリの場合ユーザーの設定する項目が少ないため、全てのイベントをメインイベントハンドラで処理するように設計されている。
【００２２】
フォトプリントアプリでは、Ｗ−Ｂ０がメイン画面となり、ＭＰ−Ｂ０がメインイベントハンドラである。フォトプリントアプリではユーザーの設定する項目が多岐に及ぶため、メインイベントハンドラではアプリ切換えイベントのみを処理し、ユーザーからのインタラクティブな操作は全てサブイベントハンドラで処理するように設計されている。Ｗ−Ｂ１、Ｗ−Ｂ２はフォトプリントアプリ固有のサブ画面である。コピーアプリと同様にシステムの共通画面であるＷ−Ｃ１、Ｗ−Ｃ２も使用する。ここで、Ｗ−Ｃ１、Ｗ−Ｃ２は画面は共通であるが、イベントハンドラはアプリが個別に作成して関連付けることができ、アプリに応じた固有処理が可能となっている。例えば、Ｗ−Ｃ２画面では画面タイトルをコピーアプリの場合は「コピー中です」、フォトプリントアプリの場合には「印刷中です」とする、というようなことができる。
【００２３】
先ず、マルチファンクションプリンタの電源をＯＮした直後は、全てのアプリケーションはメインイベントハンドラだけが起動されたアイドル状態となり、図示しないがアイドル状態アプリが画面を表示する。
【００２４】
この状態で、カードスロットに写真データの入ったメモリーカードが挿入されると、そのイベントがカードマネージャからフォトプリントアプリに通知され、フォトプリントアプリからシステムに対してアプリのアクティブ化要求がなされる。システムでは、他の機能が動作していないので、フォトプリントアプリに対してアクティブ化を許可する。フォトプリントアプリはアクティブ化を許可されると画面Ｗ−Ｂ１にイベントハンドラＰ−Ｂ１を関連付けて表示させる。メインイベントハンドラの画面Ｗ−Ｂ０はブランクであり、ユーザーから見ると最初に見るフォトプリントアプリの画面はＷ−Ｂ１に見える。
【００２５】
次に、Ｗ−Ｂ１画面におけるイベント処理の説明を図５のフローチャートに従って説明する。
【００２６】
先ず、Ｗ−Ｂ１画面において「→」キーが押された場合は、先ずＭＰ−Ｂ１に「→キーイベント」を送付する。ＭＰ−Ｂ１はイベントを「→キーイベント」を受け取ると、メモリーカードから現在表示している次の写真を検索して画面に表示させる。一連の処理が終了したらＭＰ−Ｂ１はハンドラの戻り値をイベント処理済みとして終了する（ステップＳ５−１）。システムはハンドラの戻り値を見てイベントが処理されたことを解釈し（ステップ５−２）、「→キーイベント」に関する処理を終了する。
【００２７】
Ｗ−Ｂ１画面において「ＳＴＯＰ」キーが押された場合は、ステップＳ５−１で同様にＭＰ−Ｂ１に対して「ＳＴＯＰキーイベント」が送付される。しかし、Ｐ−Ｂ１ではＳＴＯＰキーイベントに対しては行うことがないため、イベントハンドラは何もせずに戻り値をイベント未処理として終了する。システムはイベントハンドラの戻り値を参照して、イベントが処理されなかったことを解釈する（ステップ５−２）とステップＳ５−３へ進む。ステップＳ５−３では、処理したハンドラがメインイベントハンドラかどうかをチェックする。Ｐ−Ｂ１はサブイベントハンドラなので、ステップＳ５−４に進む。
【００２８】
システムは「ＳＴＯＰキーイベント」をフォトプリントアプリのメインイベントハンドラであるＭＰ−Ｂ０に送付する（ステップ５−４）。ＭＰ−Ｂ０ではキーイベントに対応した処理は行わないのでイベント未処理で処理を終了し、「ＳＴＯＰキーイベント」に対する処理は終了する。
【００２９】
Ｗ−Ｂ１画面において、「スタート」キーが押された場合は、ステップＳ５−１でイベントを送付されたＭＰ−Ｂ１は、「スタートキーイベント」を印刷開始トリガーとして解釈し、印刷ジョブを生成するとともに、印刷中であることを示すＷ−Ｃ２画面表示する。そして、プロシージャの戻り値をイベント処理済みとして終了する。システムでは、ステップＳ５−２からステップＳ５−３以降の処理をスキップして「スタートキーイベント」に対する処理を終了する。ここでＭＰ−Ｂ１によって新たな画面Ｗ−Ｃ２が表示されるので、以後のイベント送付先はＷ−Ｃ２に対応したＰ−ＣＢ２イベントハンドラに変更される。
【００３０】
次に、フォトプリントアプリにおいてＷ−Ｃ１画面が表示されている時に、「コピー」キーが押された場合の処理について説明する。
【００３１】
「コピー」キーは直接コピーアプリのメインイベントハンドラＭＰ−Ａ１で処理される。ＭＰ−Ａ１は、コピーキーイベントを受け取ると、システムに対して自身のアクティブ化要求が行う。システムでは、この要求を受け取ると、この時既にアクティブなアプリとして動作中のフォトプリントアプリでフォーカスを持っているＰ−ＣＢ１イベントハンドラに対して、アプリ状態切換えイベントの１つである「アプリインアクティブ化要求イベント」を送付する。イベントハンドラＰ−ＣＢ１ではアプリ状態切換えイベントは処理しないのでイベント未処理で処理を終了し（ステップＳ５−１）、ステップＳ５−３へ進む。
【００３２】
ステップＳ５−３では、Ｐ−ＣＢ１はサブイベントハンドラなのでステップＳ５０４へ処理を進める。そして、フォトプリントアプリのメインイベントハンドラＭＰ−Ｂ０によって「アプリインアクティブ化要求イベント」が処理され、システムに対してインアクティブ化許可を通知し、イベント処理済みで処理を終了する。そして、システムによりフォトプリントアプリはインアクティブ化され、次いで、コピーアプリのイベントハンドラＭＰ−Ａ１に対して「アプリアクティブ化イベント」を送付してアクティブ化することにより、ユーザーの操作対象アプリの切換えが行われる。
【００３３】
次に、Ｗ−Ｃ２画面が表示されている時、即ち、プリント駆動中に、「コピー」キーが押された場合の処理について説明する。
【００３４】
「コピー」キーは直接コピーアプリのメインイベントハンドラＭＰ−Ａ１で処理される。ＭＰ−Ａ１は、「コピーキーイベント」を受け取ると、システムに対して自信のアプリケーションのアクティブ化要求が行う。システムでは、この要求を受け取ると、この時既にアクティブなアプリとしてフォトプリントアプリが動作しているので、フォトプリントアプリでフォーカスを持っているＰ−ＣＢ２イベントハンドラに対して、「アプリインアクティブ化要求イベント」を送付する。Ｐ−ＣＢ２イベントハンドラでは、実行中の印刷ジョブを中止してまでアプリの切換えを待って欲しいので、メインイベントハンドラにイベントが転送されないように自分で解釈し、システムにアプリインアクティブ不可を通知して、ベントハンドラの戻り値をイベント処理済みで終了し、（ステップＳ５−１）ステップＳ５−２へ進む。ステップＳ５−２では、イベント処理済みなので「コピーキーイベント」に対する処理を終了する。
【００３５】
＜実施の形態２＞
実の形態１で、フォトプリントアプリでＷ−Ｃ１画面のイベント処理の説明をした。フォトプリントアプリでＷ−Ｃ１画面で「スタートキーイベント」が発生しても、Ｐ−ＣＢ１では処理されず、転送先のメインイベントハンドラＭＰ−Ｂ０でも処理されないため「スタートキーイベント」は処理されることなく終了する。
【００３６】
一方、コピーアプリのＷ−Ｃ１画面で「スタートキーイベント」が発生した場合、もしＰ−ＣＡ１イベントハンドラを未処理で終了して、コピーアプリのメインイベントハンドラＭＰ−Ａ１に「スタートキーイベント」が転送されると、イベントハンドラＭＰ−Ａ１では「スタートキーイベント」をコピー開始のトリガーとして処理してしまう。これは、ユーザーが意図しない動作を引き起こすことになる。コピーアプリも実施例１のフォトプリントアプリと同様に、メインイベントハンドラではアプリ切換えのイベントを、サブイベントハンドラでキーイベントの処理を行うように設計変更すれば回避できるが、折角のシンプルなアプリが少し複雑化してしまうという弊害がある。
【００３７】
そこで、発生するイベントを大まかにグループ分けをして、メインイベントハンドラに転送するイベントとそうでないイベントとを区別するステップを追加して、転送しても意味のないイベントをメインイベントハンドラに転送しないようにしたのが図６に示すフローチャートでり、図７がイベントを転送するグループと転送しないグループに分けた一例である。特殊キーイベントとは実施の形態１で言うところの「コピー」キーと「フォトプリント」キーで、それ以外のキー入力で発生するイベントは「一般キーイベント」としている。
【００３８】
図６のフローチャートに従って、先に示したコピーアプリのＷ−Ｃ１画面における「スタートキーイベント」に対する処理を説明する。
【００３９】
先ず、ステップＳ６−１でスタートキーイベントがプロシージャＰ−ＣＡ１に送付され、未処理のまま終了し（ステップＳ６−１）、ステップＳ６−２でステップＳ６−３へ進む。ステップＳ６−３では、Ｐ−ＣＡ１はサブプロシージャなのでステップＳ６−４へ進む。ステップＳ６−４で現在処理中のイベントが図７の分類でどちらになっているかチェックする。その結果、一般キーイベントなので転送しないと判断され、この場面におけるスタートキーイベントに対した処理を終了する。
【図面の簡単な説明】
【００４０】
【図１】本発明の一実施形態を示すブロック図である。
【図２】アプリケーションの例を示す図である。
【図３】操作パネルの例を示す図である。
【図４】画面の例とイベントハンドラの概要を示す図である。
【図５】本発明の一実施形態を示すフローチャートである。
【図６】本発明の他の実施形態を示すフローチャートである。
【図７】イベントの分類の例を示す図である。
【符号の説明】
【００４１】
１−１    ＣＰＵ
１−２    ＲＡＭ
１−３    ＲＯＭ
１−４    Ｉ／Ｆ
１−５    キーコントローラ及びのキー
１−６    表示部
１−７    プリントエンジン
１−８    スキャナエンジン
１−９    カードスロット
１−１０  システムバス
【図１】
2006155302.tif 000003
【図２】
2006155302.tif 000004
【図３】
2006155302.tif 000005
【図４】
2006155302.tif 000006
【図５】
2006155302.tif 000007
【図６】
2006155302.tif 000008
【図７】
2006155302.tif 000009