JP2017027366A - 情報処理装置及びイベント管理方法 - Google Patents

Abstract

【課題】異なるイベントで動作するグラフィックコントローラを利用したアプリを１つの情報処理装置で動作させると、ユーザが操作部で操作を行っても一方のグラフィックコントローラを利用したアプリは動作しない。【解決手段】操作部１０６に表示しているアプリのウインドウに応じて、グラフィックコントローラ３０６／３０８に送信するイベントを変更する。またイベントの変更には、ダミーイベントの生成と送信、および、イベント座標の変換を含む。これにより、グラフィックコントローラは、入力されたイベントに応じた処理要求をアプリに出すことができる。【選択図】図３

Description

本発明は、情報処理装置の操作部を操作したときに発生するイベントを制御する技術に関する。

タッチパネルを備える情報処理装置では、ユーザがタッチパネルに表示されたオブジェクト（以下、対象または操作対象とも呼ぶ）タッチしたときに、タッチパネルのデバイスドライバによって発生するタッチイベントを、情報処理処置内部のソフトウエア（グラフィックコントローラ）で処理してタッチされた操作対象を選択するのが一般的である。一方、マウスを用いて選択する場合、操作対象にマウスを移動したときにマウスのデバイスドライバによって発生するエンターイベントと、マウスでクリックしたときにマウスのデバイスドライバによって発生するタッチイベントの両方のイベントを、グラフィックコントローラで処理して操作対象を選択するのが一般的である。そのため、タッチパネルを用いる場合はタッチイベントのみで動作するグラフィックコントローラを利用し、マウスを用いる場合はエンターイベントとタッチイベントで動作するグラフィックコントローラを利用するのが一般的である。なお近年では、ユーザの操作性を向上するために、タッチパネルドライバで検知したイベントの種別に応じて、検知したイベントを補正して処理を変更する技術も知られている（特許文献１参照）。

グラフィックコントローラをバージョンアップによる更新や別のものに変更することで、必要なイベントが変わることがある。例えば、タッチパネルで用いられるグラフィックコントローラが、マウスで用いられるグラフィックコントローラに変更されることがある。この場合、オブジェクトの選択のために、変更前はタッチイベントのみを必要としたが、変更後はエンターイベントとタッチイベントの両方が必要となる。なおグラフィックコントローラは、ライセンスなどの問題で修正するのが難しいケースが多いうえ、もし修正できたとしてもそれを利用するアプリの修正やリコンパイルが発生することが多い。そのため、グラフィックコントローラが必要とするイベントのみを変えることは難しいのが一般的である。

特開2014-197315号公報

タッチパネルを備える情報処理装置において、複数のアプリケーション（以下、アプリという）が動作しており、アプリの実装言語毎に異なる複数のグラフィックコントローラが存在している。このとき、ある１つのアプリのためのグラフィックコントローラを更新もしくは別のものに変更することで、或る操作に対応するためにグラフィックコントローラが必要とするイベントが変わることがある。たとえば前述したように、あるアプリのためのタッチパネル用のグラフィックコントローラとしてマウス用のグラフィックコントローラを用いたり、あるいは新たなグラフィクスコントローラを用いたりすると、選択操作のために必要とするイベントはタッチイベントからエンターイベント＋タッチイベントへと変わることがある。この場合、ひとつの操作に対応するために必要となるイベントが互いに異なる複数のグラフィックコントローラがひとつの情報処理装置で動作することになる。そのため、タッチパネルドライバが発生するイベントは変わらないために、そのドライバが発生するイベントに対応したグラフィックコントローラ、たとえば変更されていない方のグラフィックコントローラしか動作できない。その結果、たとえばユーザが操作部でボタン選択などの操作を行っても、動作していたはずのアプリが動作しなくなり、動作するアプリと動作しないアプリとが生じ得る。

本発明は上記従来例に鑑みて成されたもので、グラフィックコントローラが動作するイベントが変更されても、操作と操作に対応するアプリケーションの動作とがその変更によって変わることのない情報処理装置およびイベント管理方法を提供することを目的とする。

上記目的を達成するために本発明は以下の構成を有する。すなわち、
入力デバイスの操作に応じて発生したイベントを、該イベントの送信先である、受信したイベントに応じた処理要求をアプリケーションに対して入力するグラフィックコントローラ部の種類と前記イベントの種類とに応じて変更する変更手段と、
前記変更手段により変更されたイベントを前記グラフィックコントローラ部に送信する送信手段とを有する。

本発明により、グラフィックコントローラが動作するイベントが変更されても、操作と操作に対応するアプリケーションの動作とがその変更によって変わることがない。また、異なるイベントで動作するグラフィックコントローラをもつ情報処理装置において、既存のアプリを作り直すことなく、ユーザがタッチパネルの操作を行うことが可能となる。これにより、アプリの互換性(グラフィックコントローラが変わってもアプリは変更なしで動作可能であるという互換性)を維持することができる。

本発明の各実施形態に共通する画像形成装置１００のコントローラユニット１２０を表すブロック図である。 本発明の各実施形態に共通する画像形成装置１００の操作部１０６および周辺の構成を示すブロック図である。 本発明の各実施形態に共通するソフトウエアのモジュール構成を表す図である。 画像形成装置１００のHDD１０４に記憶された描画コントローラ管理テーブルを表すイメージ図である。 画像形成装置１００の操作部１０６に表示される一画面例である。 画像形成装置１００の操作部１０６に表示される一画面例である。 本発明の各実施形態に共通するユーザ操作に応じたイベント制御の処理を表すフローチャート図である。 本発明の第２の実施形態におけるユーザ操作に応じたイベント制御の処理を表すフローチャート図である。 画像形成装置１００の操作部１０６に表示される一画面例である。 画像形成装置１００の操作部１０６に表示される一画面例である。

以下、本発明を実施するための形態について、図面を用いて説明する。

［第１の実施形態］
最初に、情報処理装置の一実施例である画像形成装置のコントローラユニットの説明を行う。
＜画像形成装置のコントローラユニットの構成＞
図１は、本発明の各実施形態に係る画像形成装置１００のコントローラユニットの内部構造を示すブロック図である。コントローラユニット１２０は、各種制御プログラムを実行するCPU１０１を有する。CPU１０１は、ROM１０３に格納されているブートプログラムに基づきシステムを起動し、このシステム上でHDD(ハードディスク装置)１０４に格納されている制御プログラムを読み出してRAM１０２をワークエリアとして所定の処理を実行する。この制御プログラムにより、Java（登録商標）プログラムなどの所定の制御を実行することが可能である。HDD１０４には、上記各種制御プログラムが格納されるとともに、画像データや後述するネットワーク部１０７が有するすべての通信手段に関する情報を格納する。CPU１０１には、RAM１０２、ROM１０３、HDD１０４がシステムバス１１１を介して接続されている。さらに操作部I/F１０５、ネットワーク部１０７、イメージバスI/F１０９、電源管理部１１０がシステムバス１１１を介して接続されている。

操作部Ｉ／Ｆ１０５は、操作部（ディスプレイ）１０６との間のインターフェイス部であり、操作部１０６に表示する画像データをＲＡＭ１０２から取得して転送する処理や、操作部１０６で発生した信号をＣＰＵ１０１へ転送する処理などを行う。操作部１０６は、ユーザが操作可能なボタンなどの操作対象を表示するための表示処理と、表示処理に表示された情報をユーザが操作した信号（入力信号）を検知する入力処理を行う。操作部１０６には、後述するように座標入力デバイスであるタッチパネルと表示デバイスであるＬＣＤとが含まれる。

電源管理部１１０は、画像形成装置１００の電源OFFと電源ONの管理を行う。なお電源ONを検知した場合、上述のように、CPU１０１は、ROM１０３のブートプログラムに基づきシステムを起動し、このシステム上でHDD１０４に格納されている制御プログラムを実行する。

ネットワーク部１０７は、LAN１０８に接続され、LAN１０８を介した情報の入出力を行う。LAN回線にwebサーバや外部装置４００が接続されている場合は、そのサーバからLAN１０８を介して情報を取得することが可能である。また、LAN回線内のプロキシサーバなどを介して、インターネットに接続し、インターネット上のwebサーバからwebコンテンツを取得することも可能である。

イメージバスI/F１０９は、システムバス１１１と画像バス１１２とを接続し、データ構造を変換するバスブリッジである。画像バス１１２は、画像データを高速で転送可能なPCIバスまたはIEEE１３９４規定に従うバスから構成される。画像バス１１２には、RIP(ラスタイメージプロセッサ)１１３、デバイスI/F１１４および画像処理部１１９が接続されている。RIP１１３は、PDLコードをビットマップイメージに展開する。デバイスI/F１１４は、画像入出力デバイスであるスキャナ１１６やプリンタ１１８とコントローラユニット１２０とを接続し、画像データの同期系／非同期系の変換を行う。ここでは、デバイスI/F１１４とスキャナ１１６とがケーブル１１５を介して、デバイスI/F１１４とプリンタ１１８とがケーブル１１７を介してそれぞれ接続されている。画像処理部１１９は、多値画像データに対してJPEGなど、二値画像データに対して、JBIG、MMR、MHなどの圧縮伸張処理を行う。また、入力画像データや出力画面に対して、プリンタの補正や解像度変換などの補正、加工、編集を行う。

このように、コントローラユニット１２０のCPU１０１は、各制御プログラムに基づき、システムバス１１０に接続される各種デバイスとのアクセスを総括的に制御するととともに、デバイスI/F１１４を介してスキャナ１１６から画像情報を読み込む。また、読み込んだ画像情報に対して所定の処理を施した後に該画像情報をデバイスI/F１１４を介してプリンタ１１８に出力するなどの制御を行う。さらに、ネットワーク部１０７を通じて取得した文字データや画像データの解析・変換処理を行い、HDD１０４へ保存あるいは操作部１０６での表示制御を行う。

＜ＣＰＵ１０１による操作部１０６の制御＞
図２は、図１の操作部１０６および周辺の構成を示すブロック図である。操作部１０６のタッチパネル２０３および各ハードキーのキー群２０２は、操作部Ｉ／Ｆ１０５の入力ポート２０１を介してＣＰＵ１０１に接続される。また、このタッチパネル２０３の押下位置を示す位置情報、およびキー群２０２の押下に対応するキー情報は、入力ポート２０１を介してＣＰＵ１０１に入力される。

操作部１０６のＬＥＤ２０５およびＬＣＤ２０６は、操作部Ｉ／Ｆ１０５の出力ポート２０４を介してＣＰＵ１０１に接続され、ＬＥＤ２０５の点灯およびＬＣＤ２０６の表示はＣＰＵ１０１により制御される。このタッチパネル２０３には微量な電気が流れており、ユーザがタッチすることで発生する電気量の変化からタッチ位置を検出する静電方式の装置であり、ＬＣＤ２０６の上に重なるように配置される。ユーザがＬＣＤ２０６上に表示された仮想的なボタン(以下、ボタン)などの操作対象を直接触れることで、タッチパネル２０３がその位置情報(座標)を検知する。ＣＰＵ１０１は、位置情報を検知すると、現在ＬＣＤ２０６上に表示している操作対象とその座標を元に、ユーザが選択した操作対象が何であるかを検知する。そしてＣＰＵ１０１は、ＲＯＭ１０３もしくはＨＤＤ１０４にあらかじめ記憶されている命令の中から、検知した操作対象が選択されときに実行すべき命令を検出し、この命令を実行する。これにより、ＬＣＤ２０６に表示する画面データが作成される。この画面データは、ＣＰＵ１０１が出力ポート２０４を経由してＬＣＤ２０６に送信することで、操作部１０６の表示を変更できる。なお、このようなＬＣＤ２０６でのユーザ操作時の内部処理は、これ以降の全ての説明で共通であり、以降では記載を省略する。なお、タッチパネルは上述した静電方式とは限らず、抵抗膜方式や表面弾性波方式などの他の方式であってもよい。

＜ソフトウエア構成＞
次に、画像形成装置１００のCPU１０１やHDD１０４などの各ハードウエア上で動作するソフトウエアのモジュール構成を、モジュール構成を示す図３を用いて説明する。なお、これらの各モジュールにおける処理は、CPU１０１の命令により、ROM１０３やHDD１０４に格納されているプログラムを読み出し、RAM１０２をワークエリアとして所定の処理を実行することで実現している。また、所定の処理を実行することで生成される全ての情報は、RAM１０２もしくはHDD１０４に格納する。このような各モジュールにおける処理は、特に明記しない限り同様であるため、以降ではこのようなハードウエアの記載は省略する。また、モジュール構成図３の各モジュールの詳細な処理は、後述のフローチャート図７でも説明を行う。

ドライバ部３０１は、タッチパネルドライバであり、ユーザが操作部１０６(正確には操作部１０６のLCD２０６)でタッチなどの操作を行ったときに発生するタッチイベントやリリースイベントなどの操作イベントを検知するモジュールである。操作イベントは、イベントの種類と、イベントの座標とを含む。このドライバ部３０１は、検知した操作イベントをイベント管理部３０２へ送信する。

イベント管理部３０２は、ドライバ部３０１から送信されるイベント（或いはイベント情報とも呼ぶ）を受信し、操作部１０６に表示しているアプリに応じて受信したイベントの変更や新規作成を行い、これらのイベントを後述のウインドウ管理部３０５に送信するモジュールである。イベント管理部３０２は、表示を行っているアプリケーションプログラム（以下、アプリと略称する）の特定を行う場合は後述のウインドウ管理部３０５を用い、イベントの変更や作成を行う場合は後述の送信情報変更部３０３や後述の送信イベント生成部３０４を用いる。

送信情報変更部３０３は、イベント管理部３０２からの送信情報変更求を受信し、送信情報の変更を行い、変更した情報をイベント管理部３０２に送信するモジュールである。

送信先イベント生成部３０４は、イベント管理部３０２からの送信イベント生成要求を受信し、受信した情報を元にしてダミーイベントを生成し、生成したダミーイベントをイベント管理部３０２に送信するモジュールである。

ウインドウ管理部３０５は、イベント管理部３０５からのイベントや変更した情報を受信し、操作部１０６に表示を行っているアプリに対応したグラフィックコントローラ部に、イベント送信を行うモジュールである。また、ウインドウ管理部３０５は、操作部１０６に表示するウインドウの管理も行っており、操作部１０６にどのアプリのどのウインドウを表示しているかの特定や、任意のウインドウを操作部１０６に表示することが可能である。

Cグラフィックコントローラ部３０６は、後述のCアプリ部３０７のC言語で実装されたアプリが利用するボタンやリスト、ウインドウなどの描画コントローラからなるモジュールである。なお、これらのCグラフィックコントローラ部３０６の描画コントローラは、全てウインドウ上に配置されており、１つのウインドウには複数の描画コントローラを配置することが可能である。そのため、ウインドウを切り替えることで、操作部１０６の画面を切り替えることとする。なお、描画コントローラの配置座標や描画コントローラに対応する実行処理などの情報は、アプリのプログラムに含まれていることとする。また、Cグラフィックコントローラ部３０６は、ウインドウ管理部３０５からイベントを受信すると、操作部１０６に表示しているウインドウのアプリに対して実行処理要求を送信するモジュールでもある。また上記記述では描画コントローラはコントローラであると共に表示されるオブジェクトをも指す用語として用いているが、表示される対象をウイジェットあるいはコントロールと呼んでコントローラと区別する場合もある。

Cアプリ部３０７は、C言語で実装されたアプリ(以降ではCアプリと呼ぶ)の集まりである。このCアプリ部３０７のアプリは、Cグラフィックコントローラ部３０６からの実行処理要求を受信すると、この実行処理要求に応じた処理を実行する。例えば、アプリの処理Aを実行したい場合、処理Aを実行するためのボタンAをあるウインドウ上に配置し、操作部１０６にこのウインドウを表示する。そしてユーザがこのボタンAを押下すると、Cグラフィックコントローラ部３０６はボタンAの選択を検知し、このボタンAに関連付けられた処理Aの実行要求イベントをアプリに送信する。アプリは受信したイベントに応じた処理を実行する。

Javaグラフィックコントローラ部３０８は、後述のJavaアプリ部３０９のJava言語で実装されたアプリが利用するボタンやリストなどの描画コントローラからなるモジュールである。このJavaグラフィックコントローラ部３０８は、前述のCグラフィックコントローラ部３０６と同じく、ウインドウ管理部３０５からイベントを受信すると、操作部１０６に表示しているウインドウのアプリに対して実行処理要求を送信する。

Javaアプリ部３０９は、Java言語で実装されたアプリ（以降ではJavaアプリと呼ぶ）の集まりである。このJavaアプリ部３０９のアプリは、Javaグラフィックコントローラ部３０８からのイベントを受信すると、このイベントに応じた処理を実行する。ここで、Cグラフィックコントローラ部３０６とJavaグラフィックコントローラ部３０８について、詳細な処理の説明を行う。

＜Cグラフィックコントローラ部の説明＞
最初にCグラフィックコントローラ部３０６について説明する。Cアプリ部３０７のアプリが利用する描画コントローラの情報は、あらかじめHDD104にアプリ毎にテーブル形式で記憶されており、ここではあるアプリ(アプリXとする)が利用する描画コントローラの情報が、図４であるとする。なお以降では、図４のような表で表した描画コントローラの情報を描画コントローラ管理テーブルと呼ぶことにする。図４の説明を行う。コントローラ種別は、描画コントローラの種類を表す情報であり、ウインドウやボタン、リストなどがある。IDは、各コントローラを一意に識別するための番号等の識別情報である。領域は、各コントローラの配置位置であり、ここでは左上の座標と右下の座標とにより特定している。親IDは、各コントローラを配置するベースとなるウインドウのIDである。対応動作は、各コントローラが選択されたときに行う動作である。なお以下の説明ではコントローラ種別にIDを付してコントローラを特定する。

図４(a)は、アプリXにはIDが1000のウインドウ（以下ウインドウ1000と呼ぶ。他のコントローラも同様）と、ウインドウ2000があることを表している。また図４(a)は、ウインドウ1000上にはボタン1001とボタン1002が配置されており、ウインドウ2000上にはリスト2001が配置されていることを表している。本例では、ウインドウ1000を操作部１０６に表示すると図５の画面となり、この画面でユーザが、ボタン1001を選択すると、ウインドウ2000の画面を表示する。

ここで、ボタンを選択するための内部処理について説明する。ここでの説明は、ウインドウ等のコントローラを処理の主体となり得るオブジェクトとして記述する。しかしウインドウやウイジェットに対応するオブジェクトによる処理は、たとえばグラフィックコントローラ部３０６／３０８やウインドウ管理部３０５により実行されるものとしてもよい。いずれにしてもハードウエア構成上はＣＰＵ１０１によって実行される。Cグラフィックコントローラ部３０６のボタンを選択するには、このボタンを表示しているウインドウに対して、ボタンの領域内の座標のタッチイベントとリリースイベントの両方を順番に送信する必要がある。タッチイベントとは、操作部１０６を指でタッチしたことを表すイベントで、リリースイベントは指を離したことを表すイベントである。また以降では、イベントの種別と座標を含むイベントを、操作イベントと呼ぶ。図５のボタン1001を選択する場合、Cグラフィックコントローラ部３０６は、ウインドウ1000に対する、イベント種別がタッチとリリースの操作イベントを受信する必要がある。また、ここで受信するイベントは、共にボタン1001の領域内すなわち座標が(200,200)〜(300,300)の領域内の座標である必要もある。Cグラフィックコントローラ部３０６は、これら２つの操作イベントを受信すると、ボタン1001が選択されたと認識する。そしてCグラフィックコントローラ部３０６は、ボタン1001の対応動作として、ウインドウ2000の表示要求をCアプリ部３０７のアプリ(アプリX)に送信する。

＜Javaグラフィックコントローラ部の説明＞
続いて、Javaグラフィックコントローラ部３０８の説明を行う。Javaグラフィックコントローラ部３０８は、Javaアプリ部３０９のアプリが利用可能な描画コントローラの集まりであり、描画コントローラとしてはボタンやウインドウがある。ただし、Javaグラフィックコントローラ部３０８は、ウインドウをベースとするコントローラであり、１つのウインドウ上に１つしか描画コントローラを配置することができない。そのため、図５と同じ画面を操作部１０６に表示する場合、描画管理テーブルは図４(b)となる。図４(b)は、ウインドウ5000上にウインドウ5100と、ウインドウ5200とが配置されている。そして、ウインドウ5100上にボタン5101が配置され、ウインドウ5200上にボタン5201が配置されている。なお以降では、親IDを持たないウインドウをベースウインドウと呼び、親IDを持つウインドウを子ウインドウと呼ぶ。なお以降では特に明記しない限り、単なるウインドウはベースウインドウのことを表すとする。

Javaグラフィックコントローラ部３０８は、ボタンを選択するために必要なイベントもウインドウベースのものである。Javaグラフィックコントローラ部３０８のボタンは、その選択操作に応じて、ボタンを表示しているウインドウに対して、エンターイベント、タッチイベント、リリースイベント、リーブイベントの４つのイベントを続けて送信する必要がある。エンターイベントは、指示されている位置がウインドウの領域内に入ったことを表すイベントで、リーブイベントはウインドウの領域内から出たことを表すイベントである。そのため、ボタン5101を選択する場合、Javaグラフィックコントローラ部３０８は、ウインドウ管理部３０５から子ウインドウ5100に対する４つの操作イベントを順番どおり受信する必要である。この４つの操作イベントとは、イベント種別がエンター、プレス、リリース、リーブのイベントである。また、これらのイベントの座標は、送信されたウインドウ(ベースウインドウではなく、子ウインドウ)内の座標系で示される必要がある。たとえば図４(b)のボタン5101の場合は、操作部１０６の表示画面の座標系では左上と右下の角点がそれぞれ(200,200)、(300,300)の座標で表されるが、イベントの座標は、子ウインドウの座標系で表される必要があり、例えばボタン5101は、その左上角を原点とする(0,0)〜(100,100)の座標で表されている必要がある。

以上が、本実施例のCグラフィックコントローラ部３０６とJavaグラフィックコントローラ部３０８の説明である。このように、Cグラフィックコントローラ部３０６とJavaグラフィックコントローラ部３０８は、例えば同じ選択操作について、異なるイベントを受信する必要がある。

＜イベント検知からイベント送信までの手順＞
続いて、ドライバ部３０１でイベントを検知してからCグラフィックコントローラ部３０６もしくはJavaグラフィックコントローラ部３０８にイベントを送信するまでの処理を、フローチャート図７を用いて説明する。なお、フローチャート図７の処理の説明後に、具体例の説明を行う。ここで、ドライバ部３０１は、Cグラフィックコントローラ部３０６に対応したイベントを発生する。すなわち、ドライバ部３０１の発生したイベントをそのままCアプリ部３０７のウインドウに対して入力すれば、Cアプリ部３０７はイベントに応じた処理を実行できる。

ユーザが操作部１０６で操作を行うと、ドライバ部３０１は、操作イベントを検知する(ステップ７０１)。この操作イベントには、イベントの種別とイベントが発生した座標を含む。なお、操作イベントの検出方法は、採用したタッチパネルの方式、例えば一般的な抵抗膜方式(感圧方式)もしくは静電方式の操作パネルの検出方法と同じであるため、詳細は省略する。ドライバ部３０１は、検知した操作イベントをイベント管理部３０２へ送信する。

この操作イベントを受信したイベント管理部３０２は、操作部１０６に表示しているウインドウがCアプリのウインドウかどうかの判定要求をウインドウ管理部３０５に送信する。これを受信したウインドウ管理部３０５は、操作部１０６に表示しているウインドウに関する情報（ウインドウ情報）を元に、Cアプリのウインドウを表示しているかを判定する(ステップ７０２)。そしてウインドウ管理部３０５は、この判定結果をイベント管理部３０２に送信する。

イベント管理部３０２は、ウインドウ管理部３０５から受信した判定結果からCアプリのウインドウを表示していると判断すると、ドライバ部３０１から受信した操作イベントをウインドウ管理部３０５に送信する(ステップ７０３)。これを受信したウインドウ管理部３０５は、操作部１０６に表示されているアプリのウインドウを特定し、このウインドウを含むグラフィックコントールを特定する。ここでは操作部１０６にはCアプリのウインドウを表示しているため、ウインドウ管理部３０５はCグラフィックコントローラ部３０６に対して送信先情報(ウインドウID)と、ドライバ部３０１から受信した操作イベントを送信する。これが操作部１０６にCアプリのウインドウを表示しているときの処理である。

一方、イベント管理部３０２は、操作部１０６に表示しているウインドウがCアプリのウインドウではないと判断すると(ステップ７０２がNOと判断すると)、送信先変更と座標変更を行う(ステップ７０４)。この詳細を説明する。

まず、イベント管理部３０２は、送信情報変更要求とドライバ部３０１から受信した操作イベントを、送信情報変更部３０３に送信する。これを受信した送信情報変更部３０３は、受信した操作イベントの座標から、この座標を領域内に含む子ウインドウを検索し、検索した子ウインドウのIDを送信先情報とする。さらに送信情報変更部３０３は、受信した操作イベントの座標を、子ウインドウ内の座標に変更する。たとえば、図４に示した描画管理テーブルを参照して、子ウインドウの座標が操作部１０６の座標系で示されているところを、子ウインドウの原点を（0,0）とする子ウインドウの座標系に変換する。例えば図４(b)の子ウインドウ5100のイベント座標は、Ｘ，Ｙそれぞれから200を減じた座標に変換される。なお以降では、このようにして受信した操作イベントの座標を変更したイベントを、新操作イベントと呼ぶ。送信情報変更部３０３は座標変更後に、送信先情報(子ウインドウのID)と新操作イベントをイベント管理部３０２に送信する。以上が送信先変更と座標変更の詳細の説明である。

送信情報変更部３０３から送信先情報と新操作イベントを受信したイベント管理部３０２は、送信イベント生成要求と新操作イベントを送信イベント生成部３０４に送信する。これを受信した送信イベント生成部３０４は、受信した新操作イベントのイベント種別が、タッチイベントであるかリリースイベントであるかの判定を行う(ステップ７０５)。

まず、この判定結果がタッチイベントの場合(ステップ７０５がYESの場合)の説明を行う。送信イベント生成部３０４は、受信した新操作イベントのイベント種別に応じたダミーイベントを生成する。具体的には、イベント種別がタッチの場合はイベント種別がエンターのダミーイベントを生成するする(ステップ７０６)。なお、ダミーイベントの座標はイベントタイプにかかわらず（エンターイベントの場合もリーブイベントの場合も）(0,0)とする。そして送信イベント生成部３０４は、生成したダミーイベントをイベント管理部３０２に送信する。これを受信したイベント管理部３０２は、送信情報変更部３０３から受信した送信先情報と、受信したダミーイベントをウインドウ管理部３０５に送信する(ステップ７０７)。そしてさらにイベント管理部３０２は、送信情報変更部３０３から受信した送信先情報と新操作イベントとをウインドウ管理部３０５に送信する(ステップ７０８)。これらのイベントを受信したウインドウ管理部３０５は、送信先情報を含むグラフィックコントローラ部に、受信したイベントを送信する。この結果、Javaグラフィックコントローラ部３０８は、ドライバ部３０１によりタッチイベントが発生した場合に、ダミーとして追加されたエンターイベントとタッチイベントとをウインドウズ管理部３０５から受信し、タッチイベントのイベント座標は、そのイベントの対象ウインドウの座標系で示されることとなる。以上が操作イベントのイベント種別がタッチイベントの場合の説明である。

次に、送信イベント生成部３０４での判定結果がリリースイベントの場合(ステップ７０５がNOである場合)の説明を行う。送信先イベント生成部３０４は、受信した操作イベントの種別がリリースイベントであると判定すると、ダミーのリーブイベントを生成する(ステップ７０９)。そして送信イベント生成部３０４は、生成したダミーイベントをイベント管理部３０２に送信する。これを受信したイベント管理部３０２は、送信情報変更部３０３から受信した送信先情報と新操作イベントをウインドウ管理部３０５に送信する(ステップ７１０)。そしてさらにイベント管理部３０２は、送信情報変更部３０３から受信した送信先情報と送信イベント生成部３０４から受信したダミーイベントをウインドウ管理部３０５に送信する(ステップ７１１)。これらのイベントを受信したウインドウ管理部３０５は、送信先情報を含むグラフィックコントローラ部に、受信したイベントを送信する。この結果、Javaグラフィックコントローラ部３０８は、ドライバ部３０１によりリリースイベントが発生した場合に、リリースイベントと、ダミーとして追加されたリーブイベントとをウインドウズ管理部３０５から受信し、タッチイベントのイベント座標は、そのイベントの対象ウインドウの座標系で示されることとなる。以上が操作イベントのイベント種別がリリースイベントの場合の説明である。これでフローチャート図７の説明は終了する。

＜具体例＞
最後に、このフローチャート図７の処理を、具体例を用いて説明する。図６は、本発明の各実施形態に共通する画像形成装置１００の操作部１０６の一表示例であり、画像形成装置１００の電源を入れることで(電源をONにすることで)、最初に表示される画面である。なお以降では、画像形成装置１００の電源をONしてから操作部１０６に最初に表示される画面を、初期画面と呼ぶこととする。この初期画面は、画像形成装置１００で実行可能なアプリを表示するメニュー画面であり、メインメニューアプリが表示している。

図６には、各アプリにアクセスするためのボタン６０１〜６０４が表示されている。コピーボタン６０１はコピーアプリにアクセスするためのボタンであり、センドボタン６０２はセンドアプリにアクセスするためのボタンである。また同様に、ボックスボタン６０３はボックスアプリにアクセスするためのボタンであり、ブラウザボタン６０４はブラウザアプリにアクセスするためのボタンである。コピーアプリ、センドアプリ、ボックスアプリはJavaアプリであり、メインメニューアプリとブラウザアプリはCアプリであることとする。

このような初期画面において、まずブラウザボタン６０４をタッチした場合の具体例を説明する。それから、Cアプリであるブラウザアプリの画面でボタンを選択した場合の具体例と、Javaアプリであるとコピーアプリの画面でボタンを選択した場合の具体例を説明する。

＜初期画面でブラウザボタン６０４を選択した場合＞
初期画面において、ユーザがブラウザボタン６０４上の座標(100,300)をタッチ(押下)したとする。なお本実施例の操作部１０６の押下可能な座標の範囲は(0,0)と(800,480)とを対角とする範囲であり、すなわち、Ｘ座標が０〜８００、Ｙ座標が０〜４８０の範囲とする。

ドライバ部３０１は、イベント種別がタッチ、座標が(100,300)の操作イベントを検知する（ステップ７０１）。ドライバ部３０１は、この検知した操作イベントをイベント管理部３０２に送信する。このイベントを受信したイベント管理部３０２は、ウインドウ管理部３０５に操作部１０６に表示されているウインドウがCアプリのウインドウかどうかの判定要求を送信する。

これを受信したウインドウ管理部３０５は、操作部１０６に表示されているウインドウがCアプリのウインドウであるかの判定を行う（ステップ７０２）。ここではCアプリであるメインメニューアプリのウインドウが表示されているため、ウインドウ管理部３０５は、Cアプリのウインドウであるという判定結果をイベント管理部３０２に送信する。

この判定結果を受信したイベント管理部３０２は、ドライバ部３０１から受信した操作イベントをウインドウ管理部３０５に送信する（ステップ７０３）。これを受信したウインドウ管理部３０５は、操作部１０６に表示しているウインドウを送信先情報とし、Cグラフィックコントローラ部３０６に送信先情報と受信したイベントを送信する。その後にユーザが座標(100,300)の位置から指をリリースしたとする。

ドライバ部３０１は、イベント種別がリリース、座標が(100,300)の操作イベントを検知する（ステップ７０１）。この後のCグラフィックコントローラ部３０６に操作イベントを送信するまでの処理は前述のタッチイベントの処理と同じである。ドライバ部３０１は、受信した操作イベントをイベント管理部３０２に送信する。

そしてイベント管理部３０２は、ウインドウ管理部３０５を用いて操作部１０６に表示されているウインドウがCアプリのウインドウであるかの判定を行う（ステップ７０２）。そしてイベント管理部３０２は、ドライバ部３０１から受信したイベントをウインドウ管理部３０５に送信する（ステップ７０３）。

これを受信したウインドウ管理部３０５は、Cグラフィックコントローラ部３０６に受信したイベントを送信する。Cグラフィックコントローラ部３０６は、前述のタッチイベントと今回受信したリリースイベントとから、ブラウザボタン６０４が選択されたと判断する。ここではブラウザボタン６０４にはブラウザアプリの起動処理が対応動作として記憶されていることとする。そのため、Cグラフィックコントローラ部３０６は、Cアプリ部３０７の１つであるブラウザアプリに起動処理要求を送信する。これを受信したブラウザアプリは、操作部１０６に図９のブラウザアプリの画面を表示する。以上が、初期画面でブラウザボタン６０４の選択した場合の具体例の説明である。ここで、図９の画面の説明を行う。

＜ブラウザ画面での操作＞
図９のwebブラウザ画面は、タイトル表示領域９０１、webコンテンツ表示領域９０２、設定項目表示領域９０３から構成されている。タイトル表示領域９０１は、webコンテンツ表示領域９０２に表示するwebコンテンツを表すタイトル文字列を表示する領域である。ここでは「検索入力画面」という文字列を表示指定している。webコンテンツ表示領域９０２は、指定されたURLアドレスに対応するwebコンテンツをwebページとして表したものを表示する領域である。設定項目表示領域９０３は、webブラウザに関する設定項目を表示する領域であり、ここには設定項目を表すボタン９０４〜９１２を表示する。これらのボタンの説明を行う。ボタン９０４はWebコンテンツの表示の戻るボタンであり、ボタン９０５はWebコンテンツの表示の進むボタンである。ボタン９０６はWebコンテンツの読み込み中止ボタンであり、ボタン９０７はWebコンテンツの再読み込みボタンである。ボタン９０８はホームボタンであり、あらかじめ決められたホームアドレスのWebコンテンツ表示するためのボタンである。ボタン９０９は印刷ボタンであり、このボタンを押下するとwebコンテンツ表示領域９０２に現在表示しているWebコンテンツを印刷するための印刷指示画面を表示するためのボタンである。ボタン９１０はお気に入りボタンであり、ユーザが所望するURLアドレスを選択するためのボタンである。ボタン９１１はメニューボタンであり、WEBブラウザに関する様々な設定（表示や印刷や動作に関する設定）を行うためのボタンである。ボタン９１２はURLアドレス表示ボタンであり、ここでは「http://127.0.0.1/send/ID.html」というURLアドレスを表示している。以上が、図９の画面の説明である。

＜ブラウザ画面でボタンをタッチした場合＞
この図９の画面で、座標(400,400)の位置をユーザが指でタッチしたとする。ドライバ部３０１は、イベント種別がタッチ、座標が(400,400)の操作イベントを検知する(ステップ７０１)。ドライバ部３０１は、この検知した情報をイベント管理部３０２に送信する。イベント管理部３０２は、ウインドウ管理部３０５を用いて操作部１０６に表示しているアプリのウインドウがCアプリのウインドウかどうかの判定を行うが、ここでは操作部にCアプリであるブラウザアプリが表示されている。そのため、この後の処理は、前述の初期画面で座標(100,300)をタッチしたときの処理と同じである。すなわち、イベント管理部３０２からウインドウ管理部３０５に操作イベントを送信し、ウインドウ管理部３０５からCグラフィックコントローラ部３０６にイベントを送信する。また、その後にユーザが座標(400,400)の位置から指を離したときの処理も前述の初期画面で座標(100,300)をタッチしたときの処理と同じである。ここではドライバ部３０１は検知したイベント種別がリリース、座標が(400,400)の操作イベントを検知する。その後、ドライバ部３０１はこの操作イベントをイベント管理部３０２に送信し、イベント管理部３０２からウインドウ管理部３０５に操作イベントを送信し、ウインドウ管理部３０５からCグラフィックコントローラ部３０６にイベントを送信する。

Cグラフィックコントローラ部３０６は、前述のタッチイベントと今回受信したリリースイベントから、プリントボタン９０９が選択されたと判断する。ここではプリントボタン９０９にはプリント設定画面のためのウインドウを表示する処理が対応動作として記憶されていることとする。そのため、Cグラフィックコントローラ部３０６は、ブラウザアプリにプリント設定画面のためのウインドウの表示要求を送信する。これを受信したブラウザアプリは、操作部１０６にプリント設定画面(不図示)を表示する。以上が、ブラウザアプリ画面でプリントボタン９０９を選択した場合の具体例の説明である。

＜初期画面でコピーボタン６０１を選択した場合＞
続いて、Javaアプリであるコピーアプリの画面でボタンをタッチしたときの処理の説明を行う。図６の初期画面において、コピーボタン６０１を指でタッチし、リリースする。これにより操作部１０６に図１０のコピーアプリの画面を表示する。この処理の詳細は、前述のブラウザボタン６０４をタッチ、リリースしたときの処理と、表示される画面がコピーアプリ画面である点を除いて同様であるため、説明は省略する。ここで、図１０の画面の説明を行う。

＜コピー設定画面の構成＞
図１０のコピーアプリ画面は、タイトル表示領域１００１、設定確認領域１００２、設定項目表示領域１００３から構成されている。タイトル表示領域１００１には「コピー設定画面」を表示し、設定確認領域１００２には現在の設定内容を表示している。この設定確認領域１００２には、コピーが実行可能であることを意味する「コピーできます。」と、倍率の「100%」と、用紙サイズの「A4」と、両面設定の「両面」と、置数の「１部」を表示している。また、設定項目表示領域１００３には、倍率を設定するための倍率ボタン１００４、用紙を設定するための用紙ボタン１００５、両面設定を行うための両面ボタン１００６を表示している。これらのボタン１００４〜１１０６をユーザが押下すると、各設定を行うための画面を表示する。

＜コピーアプリ画面での操作＞
この図１０の画面で、座標(400,400)の位置をユーザがタッチしたとする。ドライバ部３０１は、イベント種別がタッチ、座標が(400,400)の操作イベントを検知する(ステップ７０１)。ドライバ部３０１は、この検知した情報をイベント管理部３０２に送信する。

このイベントを受信したイベント管理部３０２は、ウインドウ管理部３０５に操作部１０６に表示されているウインドウがCアプリのウインドウかどうかの判定要求を送信する。これを受信したウインドウ管理部３０５は、操作部１０６に表示されているウインドウがCアプリのウインドウであるかの判定を行う(ステップ７０２)。ここでは、Javaアプリであるコピーアプリのウインドウが表示されているため、ウインドウ管理部３０５はCアプリのウインドウが表示されていないと判定し、この結果をイベント管理部３０２に送信する。これを受信したイベント管理部３０２は、送信情報変更部３０３に送信情報変更要求と受信した操作イベントを送信する(ステップ７０４)。

これを受信した送信情報変更部３０３は、送信先変更と座標変更を行う(ステップ７０４)。この詳細を説明する。ここでは、コピーアプリが図６の画面を表示するために使用する描画コントローラ管理テーブルは図４(c)であるとする。図４(c)は、倍率ボタン１００４をIDが11000のウインドウで表し、用紙ボタン１００５をIDが12000のウインドウで表し、両面ボタン１００６をIDが13000のウインドウで表している。この描画コントローラ管理テーブルは、前述の図４(b)と同じ形式であるため、詳細な説明は省略する。

送信情報変更部３０３は、イベント管理部３０２からの情報を受信すると、受信した操作イベントの座標が(400,400)であるため、この座標を含む子ウインドウを描画コントローラ管理テーブルから検索する。ここでは座標(400,400)は、IDが13000の子ウインドウ（すなわち両面ボタン）に該当するため、この子ウインドウを送信先に設定する(送信先をIDが13000のウインドウに設定する)。なおイベント座標を含む子ウインドウが見つからない場合は、ベースウインドウ(IDが10000のウインドウ)を送信先に設定することとする。さらに送信情報変更部３０３は、受信したイベントの座標をこの子ウインドウ内の座標に変換する。ここでは、受信したイベントの座標が(400,400)であり、子ウインドウの左上の座標（すなわち原点）が(350,380)であるため、子ウインドウ内の座標は、イベント座標から原点座標を差し引いた座標(50,20)となる。そして送信情報変更部３０３は、子ウインドウ内の座標からなる新操作イベント(イベント種別がタッチで、座標(50,20))と送信先情報(IDが13000のウインドウ)をイベント管理部３０２に送信する。

このイベントを受信したイベント管理部３０２は、送信イベント生成部３０４に送信イベント生成要求と新操作イベントを送信する。

これを受信した送信イベント生成部３０４は、受信した新操作イベントのイベント種別が、タッチであるかの判定を行う(ステップ７０５)。ここではイベント種別はタッチであるため、送信イベント生成部３０４はダミーのエンターイベントを生成し(ステップ７０６)、このダミーイベントをイベント管理部３０２に送信する。このステップ７０６で生成するダミーイベントは、イベント種別はエンター、座標(0,0)のイベントである。

これを受信したイベント管理部３０２は、ウインドウ管理部３０５に送信情報変更部３０３から受信した送信先情報とダミーイベントを送信する(ステップ７０７)。ここで送信する情報は、その送信先が、IDが13000のウインドウであり、イベント種別がエンターで座標(0,0)の情報である。そしてさらにイベント管理部３０２は、送信情報変更部３０３から受信した新操作イベントと送信先情報をウインドウ管理部３０５に送信する(ステップ７０８)。ここで送信する情報は、その送信先が、IDが13000のウインドウであり、イベント種別がタッチで座標(50,20)の情報である。これらのイベントを受信したウインドウ管理部３０５は、受信したイベントをJavaグラフィックコントローラ部３０８に送信する。以上が操作イベントのイベント種別がタッチイベントである場合の説明である。

次に、操作イベントのイベント種別がリリースイベントである場合の説明を行う。図１０の画面で、座標(400,400)の位置をユーザが指をリリースしたとする。ドライバ部３０１は、イベント種別がリリース、座標が(400,400)の操作イベントを検知する(ステップ７０１)。ドライバ部３０１は、この検知した情報をイベント管理部３０２に送信する。

このイベントを受信したイベント管理部３０２は、前述のタッチイベントと同様に、操作部１０６に表示しているウインドウの判定を行い(ステップ７０２)、送信情報変更部３０３を用いて送信情報の変更を行う(ステップ７０４)。その後、イベント管理部３０２は、送信イベント生成部３０４に送信イベント生成要求と新操作イベントを送信する。これを受信した送信イベント生成部３０４は、受信した新操作イベントのイベント種別が、タッチイベントであるかの判定を行う(ステップ７０５)。

ここではイベント種別はリリースであるため、送信イベント生成部３０４はダミーのリーブイベントを生成し(ステップ７０９)、生成したイベントをイベント管理部３０２に送信する。このステップ７０で生成するダミーイベントは、イベント種別はリーブ、座標(0,0)のイベントである。これを受信したイベント管理部３０２は、送信情報変更部３０３から受信した新操作イベントと送信先情報をウインドウ管理部３０５に送信する(ステップ７１０)。ここで送信する情報は、送信先がIDが13000のウインドウであり、イベント種別がリリースで座標(50,20)の情報である。そしてさらにイベント管理部３０２は、ダミーイベントと送信先情報をウインドウ管理部３０５に送信する(ステップ７１１)。ここで送信する情報は、送信先がIDが13000のウインドウであり、イベント種別がリーブで座標(0,0)の情報である。以上が操作イベントのイベント種別がリリースイベントである場合の説明である。

Javaグラフィックコントローラ部３０８は、前述のエンターイベントとタッチイベント、そして今回受信したリリースイベントとリーブイベントから、両面ボタン１００６が選択されたと判断する。ここでは両面ボタン１００６には両面設定画面のためのウインドウを表示する処理が対応動作として記憶されていることとする。そのため、Javaグラフィックコントローラ部３０８は、コピーアプリに両面設定画面のためのウインドウの表示要求を送信する。これを受信したコピーアプリは、操作部１０６に両面設定画面(不図示)を表示する。以上が、コピーアプリ画面で両面ボタン１００６を選択した場合の具体例の説明である。以上が、コピー画面でユーザが操作を行った場合の具体例である。

上記のように、操作部１０６に表示されているアプリのウインドウに応じて送信するイベント数やイベントの情報を変更することができる。これにより、異なるイベントで動作するグラフィックコントローラ部３０６、３０８を備える画像形成装置１００においても、既存アプリの変更なしにアプリを動作させることが可能となる。

＜派生形１＞ * ダミーイベントの座標
上記実施形態では、フローチャート図７のステップ７０６とステップ７０９で生成するダミーイベントの座標は、ダミーであることを明示的にするため(0,0)にした。しかし、座標はタッチもしくはリリースの操作イベントに含まれる座標と同じでもよい。これにより、受信した座標をそのまま使うこともできる。

＜派生形２＞ * アプリの処理は、タッチでもリリースでも良い
上記実施形態では、グラフィックコントローラ部はタッチとリリースの両方のイベントで描画コントローラが選択されたと判断したが、タッチイベントのみで選択されたと判断しても良い。これにより、より操作部１０６の表示切り替えを早いタイミングで行うことができ、ユーザの操作性が向上することがある。

＜派生形３＞ *イベントの送信先の判定
上記実施形態では、フローチャート図７のステップ７０２で操作部１０６にCアプリのウインドウが表示されているかどうかで判断したが、Cアプリが表示を行っているかどうかで判断しても良い。すなわちイベントの送信先の判定はウインドウではなく、表示しているアプリに基づいても良い。これにより、１つのアプリが１つのウインドウしか利用しない場合は、処理を高速に行うことが可能となる。

［第２の実施形態］
第１の実施形態では、イベント検知部３０１で検知したイベントはタッチイベントとリリースイベントのみであった。しかし、操作部１０６にタッチした指を、リリースせずに動かすことで発生するムーブイベントをイベント検知部３０１で検知することもある。本実施形態では、ムーブイベントが発生した場合を、フローチャート図８を用いて説明する。Javaアプリ部３０９及びJavaグラフィックコントローラ部３０８は、たとえばムーブイベントが入力されると、スライド操作が行われたものとして、表示されたウインドウとの位置関係に応じてスライド操作に対応する処理を実行する。その際、Javaグラフィックコントローラ部３０８は、ムーブイベントのみでスライド操作が行われたものと判定することができるものとする。なお、基本的な処理や制御は第１の実施形態と同じであるため、第１の実施形態と異なる点のみを説明する。

ユーザがタッチ操作を行った後に、操作部１０６でムーブ操作を行ったこととする。このとき、ドライバ部３０１は、イベント種別がムーブであるイベントを検知する(ステップ７０１)。操作部１０６にCアプリのウインドウが表示されている場合は、第１の実施形態と同じく、イベント管理部３０２はドライバ部３０１から受信したイベントをそのままウインドウ管理部３０５に送信する。一方、操作部１０６にJavaアプリのウインドウが表示されている場合は、ステップ７０４の送信先と座標変換処理は第１の実施形態と同じ処理であるが、イベント種別の判定処理(フローチャート図７のステップ７０５)が第１の実施形態とは異なる。ここで、イベント種別がムーブの場合の処理の説明を行う。

イベント管理部３０２からの送信イベント生成要求を受信した送信イベント生成部３０４は、受信した操作イベントのイベント種別を判定する(ステップ８０１)。ここでイベント種別がタッチもしくはリリースの場合は、第１の実施形態と同じ処理を行う。しかし、イベント種別がムーブの場合は、送信イベント生成部３０４はダミーイベントの生成を行わず、送信イベントを生成しない情報をイベント管理部３０２に送信する。

これを受信したイベント管理部３０２は、送信情報変更部３０３から受信した送信先情報に、送信情報変更部３０３から受信した新操作イベントを送信する(ステップ８０２)。つまり、送信先は子ウインドウであり、イベント種別はムーブで、座標は子ウインドウ内の座標に変換した座標である操作イベントを送信する。このため、第１の実施形態のようにムーブ操作の場合は、ダミーイベントの生成を行わない。以上が、イベント種別がムーブの場合の処理の説明である。

上記のようにグラフィックコントローラに対するダミーイベントが不要なイベントについてはダミーイベントの送信を行わない。このためグラフィックコントローラは、その種類にかかわらず、発生したイベントについて適切な動作を行うことができる。また、ウインドウ管理部３０５への不要なイベントの送信が減り、システム全体で処理する情報量を抑えることができる。

上記例ではムーブイベントについてはダミーイベントを生成せず、送信もしない例を説明したが、グラフィックコントローラがダミーイベントを必要としないイベントについては、イベント管理部３０２は、発生したイベントをそのままウインドウ管理部３０３を介してグラフィックコントローラに送信すればよい。

また実施形態１，２では、たとえば選択操作のために用いられるタッチイベントおよびリリースイベントを例として説明した。しかし、これら以外のイベントであっても、グラフィックコントローラ部がダミーイベントを必要とするイベントについては、実施形態１，２と同様に、ダミーイベントの生成と適切な順序に従う付加とを行う。さらに、ダミーイベントが必要となるイベントについて、当該イベントとダミーイベントとをウインドウを表示するアプリケーションごとに関連づけた表などを管理し、表に従ってダミーイベントを生成・付加することで、より柔軟な対応が可能となる。

また上記例ではダミーイベントを付加する例を説明したが、逆にドライバ部３０１により発生したイベントをイベント管理部で削除するように構成してもよい。たとえばドライバ部３０１がタッチを検出した場合には、まずエンターイベントを発生し、続けてタッチイベントを発生するように構成されていてもよい。この場合には、Javaアプリのウインドウに対してイベントはそのまま送信され、Cアプリのウインドウに対しては、タッチイベントに先行するエンターイベントがイベント管理部３０２により削除された上で、タッチイベントのみが送信される。リリースイベントとリーブイベントについても同様である。

さらに、上記実施形態では、操作部１０６は透明なタッチパネル２０３を表示部であるＬＣＤ２０６に重ねた構成としていたが、タッチパネル２０３を表示部から分離した構成についても、本実施形態に係る発明を適用することが可能である。

［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

３０１：ドライバ部、３０２：イベント管理部、３０３：送信情報変更部、３０４：送信イベント生成部、３０５：ウインドウ管理部、３０７：Cアプリ部、３０９：Javaアプリ部

Claims (11)

1. 入力デバイスの操作に応じて発生したイベントを、該イベントの送信先である、受信したイベントに応じた処理要求をアプリケーションに対して入力するグラフィックコントローラ部の種類と前記イベントの種類とに応じて変更する変更手段と、
   前記変更手段により変更されたイベントを前記グラフィックコントローラ部に送信する送信手段と
   を有することを特徴とする情報処理装置。
2. 前記変更手段は、前記操作に応じて発生したイベントに、前記イベントの送信先である前記グラフィックコントローラ部の種類と前記イベントの種類とに応じたダミーイベントを追加することを特徴とする請求項１に記載の情報処理装置。
3. 前記変更手段は、前記イベントの送信先である前記グラフィックコントローラ部が、前記操作に応じて発生したイベントに加えて必要とするイベントを前記ダミーイベントとして追加することを特徴とする請求項２に記載の情報処理装置。
4. 前記変更手段は、前記操作に応じて発生したイベントがタッチイベント又はリリースイベントであり、かつ、前記イベントの送信先である前記グラフィックコントローラ部が、前記タッチイベントについてはエンターイベントを、前記リリースイベントについてはリーブイベントをそれぞれ必要とする種類である場合には、前記操作に応じて発生したイベントがタッチイベントであればエンターイベントを前記ダミーイベントとして追加し、前記操作に応じて発生したイベントがリリースイベントであればリーブイベントを前記ダミーイベントとして追加することを特徴とする請求項２又は３に記載の情報処理装置。
5. 前記変更手段は、前記操作に応じて発生したイベントの座標を、前記イベントの送信先である前記グラフィックコントローラ部の種類に応じて変換することを特徴とする請求項１乃至４のいずれか一項に記載の情報処理装置。
6. 前記変更手段は、前記イベントが発生したウインドウを表示しているアプリケーションに対応したグラフィックコントローラ部を、前記イベントの送信先であると判定することを特徴とする請求項１乃至５のいずれか一項に記載の情報処理装置。
7. 複数の前記グラフィックコントローラ部を有することを特徴とする請求項１乃至６のいずれか一項に記載の情報処理装置。
8. 前記複数のグラフィックコントローラ部それぞれは、アプリケーションを記述する言語に対応し、実行されるアプリケーションに応じて用いられることを特徴とする請求項７に記載の情報処理装置。
9. 前記入力デバイスの操作に応じてイベントを発生するドライバと、
   前記グラフィックコントローラ部からの前記処理要求に応じた処理を実行するアプリケーションと
   を更に有することを特徴とする請求項１乃至８のいずれか一項に記載の情報処理装置。
10. 入力デバイスの操作に応じて発生したイベントを、該イベントの送信先である、受信したイベントに応じた処理要求をアプリケーションに対して入力するグラフィックコントローラ部の種類と前記イベントの種類とに応じて変更する変更手段と、
    前記変更手段により変更されたイベントを前記グラフィックコントローラ部に送信する送信手段と
    してコンピュータを機能させるためのプログラム。
11. 入力デバイスの操作に応じて発生したイベントを、該イベントの送信先である、受信したイベントに応じた処理要求をアプリケーションに対して入力するグラフィックコントローラ部の種類と前記イベントの種類とに応じて変更する変更工程と、
    前記変更工程により変更されたイベントを前記グラフィックコントローラ部に送信する送信工程と
    を有することを特徴とするイベント管理方法。

Images