(57)【特許請求の範囲】
【請求項１】
画面を出力し，画面上で発生したイベントに対するデータ処理を行うイベントドリブン型アプリケーションから要求された画面制御を行う画面制御装置であって，
それぞれ異なる画面名を有する複数の画面を重ね合わせ，一つの画面名が付与された一つの画面を構成することを示す画面構成定義情報を記憶する画面構成定義情報記憶手段と，
前記イベントドリブン型アプリケーションからの前記一つの画面名を指定した画面生成要求に対し，前記画面構成定義情報記憶手段を参照し，あらかじめ登録された複数の画面を重ね合わせることにより一つの画面を生成する画面生成手段と，
前記イベントドリブン型アプリケーションからの前記一つの画面へのイベント登録要求に対し，前記画面構成定義情報記憶手段を参照することにより，登録対象の画面が複数の画面を重ね合わせた画面であるかどうかを判別し，複数の画面を重ね合わせたものである場合には，その複数の画面のそれぞれに属する要求されたイベントを登録するイベント登録手段と，
前記イベント登録手段によって登録したイベントが，重ね合わせた複数の画面の一つで発生した場合に，イベントの発生元の画面名を前記重ね合わせた複数の画面によって構成される一つの画面の画面名に変更して前記イベントドリブン型アプリケーションに通知するイベント通知手段とを備えた
ことを特徴とするイベントドリブン型アプリケーションの画面制御装置。
【請求項２】
請求項１記載のイベントドリブン型アプリケーションの画面制御装置において，
前記画面構成定義情報記憶手段が記憶する画面構成定義情報は，少なくとも前記イベントドリブン型アプリケーションが指定する前記一つの画面名と，画面を重ね合わせるときの台紙となるベース画面の画面名と，前記ベース画面に重ね合わせる１または複数の画面のそれぞれの重ね合わせ画面名と，前記ベース画面に重ね合わせる１または複数の画面のそれぞれのベース画面上における重ね合わせの位置を示す情報とを含む
ことを特徴とするイベントドリブン型アプリケーションの画面制御装置。
【請求項３】
請求項２記載のイベントドリブン型アプリケーションの画面制御装置において，
前記画面生成手段は，前記ベース画面に重ね合わせる１または複数の画面のそれぞれの背景色を透明に設定する
ことを特徴とするイベントドリブン型アプリケーションの画面制御装置。
【請求項４】
画面を出力し，画面上で発生したイベントに対するデータ処理を行うイベントドリブン型アプリケーションから要求された画面制御を行うための，画面生成手段と，イベント登録手段と，イベント通知手段と，それぞれ異なる画面名を有する複数の画面を重ね合わせて一つの画面名が付与された一つの画面を構成することを示す画面構成定義情報を記憶する画面構成定義情報記憶手段とを備えるコンピュータシステムにおける画面制御方法であって，
前記画面生成手段が，前記イベントドリブン型アプリケーションからの前記一つの画面名を指定した画面生成要求に対し，前記画面構成定義情報記憶手段を参照し，あらかじめ登録された複数の画面を重ね合わせることにより一つの画面を生成する過程と，
前記イベント登録手段が，前記イベントドリブン型アプリケーションからの前記一つの画面へのイベント登録要求に対し，前記画面構成定義情報記憶手段を参照することにより，登録対象の画面が複数の画面を重ね合わせた画面であるかどうかを判別し，複数の画面を重ね合わせたものである場合には，その複数の画面のそれぞれに属する要求されたイベントを登録する過程と，
前記イベント通知手段が，前記イベント登録手段により登録したイベントが，重ね合わせた複数の画面の一つで発生した場合に，イベントの発生元の画面名を前記重ね合わせた複数の画面によって構成される一つの画面の画面名に変更して前記イベントドリブン型アプリケーションに通知する過程とを有する
ことを特徴とするイベントドリブン型アプリケーションの画面制御方法。
【請求項５】
画面を出力し，画面上で発生したイベントに対するデータ処理を行うイベントドリブン型アプリケーションから要求された画面制御を，コンピュータに実行させるための画面制御プログラムであって，
前記コンピュータを，
それぞれ異なる画面名を有する複数の画面を重ね合わせ，一つの画面名が付与された一つの画面を構成することを示す画面構成定義情報を記憶する画面構成定義情報記憶手段と，
前記イベントドリブン型アプリケーションからの前記一つの画面名を指定した画面生成要求に対し，前記画面構成定義情報記憶手段を参照し，あらかじめ登録された複数の画面を重ね合わせることにより一つの画面を生成する画面生成手段と，
前記イベントドリブン型アプリケーションからの前記一つの画面へのイベント登録要求に対し，前記画面構成定義情報記憶手段を参照することにより，登録対象の画面が複数の画面を重ね合わせた画面であるかどうかを判別し，複数の画面を重ね合わせたものである場合には，その複数の画面のそれぞれに属する要求されたイベントを登録するイベント登録手段と，
前記イベント登録手段によって登録したイベントが，重ね合わせた複数の画面の一つで発生した場合に，イベントの発生元の画面名を前記重ね合わせた複数の画面によって構成される一つの画面の画面名に変更して前記イベントドリブン型アプリケーションに通知するイベント通知手段として
機能させるためのイベントドリブン型アプリケーションの画面制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，イベントドリブン型アプリケーションの画面制御装置に関し，特に，Ｊａｖａ（登録商標）アプリケーション等のイベントドリブン型アプリケーションの画面制御において，画面定義が冗長に増えないようにするとともに，利用するアプリケーションに影響を与えないようにし，かつ性能の劣化を防ぐことを可能にした画面制御技術に関するものである。
【背景技術】
【０００２】
コンピュータを用いて業務を遂行するためのアプリケーションプログラム（以下，単に「アプリケーション」という）では，通常，多くの画面を用いてユーザへの情報の提示およびユーザからのデータの入力等を行う。このようなアプリケーションが用いる画面は，一般に画面全体のすべてにわたって異なる内容を持つものよりも，画面中の基本的な部分は共通で，一部分だけが異なるというものが多い。このような場合でも，従来，プログラム開発者は一つ一つの画面について別々に作成することを行っていた。
【０００３】
以下，図１４〜図１７に従って，従来の画面作成および画面制御の例について説明する。例えば図１４に示すように，既存の画面Ａ０および画面Ｂ０があり，それぞれに項目ｃ，項目ｄを追加して，新しい画面Ａ１および画面Ｂ１を作成するものとする。
【０００４】
このような画面の作成を，アプリケーションが行う場合には，例えば図１５に示すように，既存の画面全体の資産（画面定義情報）を利用し，アプリケーションにおける画面作成プログラムを変更することにより画面Ａ０，Ｂ０にそれぞれ項目ｃと項目ｄを加え，新しい画面Ａ１，画面Ｂ１を作成することを行っていた。しかし，この方法は，プログラム開発者が構築される画面の資産を十分に理解する必要があるだけでなく，画面作成処理のプログラムをコーディングする必要があり，プログラム開発者の負担が大きいという問題があった。
【０００５】
近年，このような画面制御のプログラム開発負担を軽減するため，例えばＶｉｓｕａｌ  Ｂａｓｉｃ（登録商標）やＪａｖａ（登録商標）などに代表されるようなＧＵＩ（Graphical User Interface）ツールが画面の作成に用いられるようになってきた。
【０００６】
図１６は，ＧＵＩツールを用いた画面作成の例を示す。ＧＵＩツールを用いて画面を作成する場合，あらかじめ用意された画面要素の部品を，画面のフォームに貼り付けることにより，目的とする画面を作成することができ，これに伴ってボタン等の画面に関する各種リソースも自動生成することができるので，図１５のようにプログラムを書いて画面を作成する場合に比べて，画面は簡易に作成することができるようになった。しかし，一方で，画面の定義情報は画面単位で作成されるため，通常，一枚ずつの画面のパターン毎に画面定義を作成することとなり，その全画面の資産は従来のプログラミングによる画面作成よりも増加してしまう。
【０００７】
図１７は，ＧＵＩツールによって作成された画面Ｂ１についてのイベント登録およびイベント通知処理の説明図である。以下では，イベントドリブン型アプリケーションを実装する環境として，Ｊａｖａを用いた例に従って説明する。Ｊａｖａ言語の場合，図１６のようなＧＵＩツールによって作成された画面定義は，画面を構成する際に必要となるサイズ，属性等の情報を記述したものであり，ファイルの拡張子が「．ｊａｖａ」であるソースプログラムの形式で保持される。このＧＵＩ操作で作成された画面定義は，「パネル」と呼ばる。
【０００８】
アプリケーション２が，画面Ｂ１を表示し，画面Ｂ１へのユーザの入力に従ってデータを処理する場合，例えば図１７に示すような処理を行う。まず，画面制御部１００に対して画面Ｂ１生成処理の依頼を行う。画面制御部１００では，画面Ｂ１の定義情報を読み込み，画面入出力制御部３に対し画面Ｂ１の生成を通知する。画面入出力制御部３は，Ｊａｖａの制御プログラムである。
【０００９】
次に，アプリケーション２からのイベント登録処理の依頼により，画面制御部１００は，画面Ｂ１のイベント登録を行う。イベント登録とは，画面上で発生するイベント（ユーザ操作等）と，その処理を行うアプリケーション処理部との紐付けを行うための処理を意味する。この処理を行うことにより，画面上にて発生したイベントを，アプリケーション２側で処理することが可能となる。イベントとは，ユーザが画面上のボタンをクリックしたとか，データ項目の入力域にユーザがデータを書き込んだというような事象をいう。
【００１０】
次に，アプリケーション２は，画面制御部１００に対し画面Ｂ１の表示依頼を行い，これにより画面入出力制御部３への画面Ｂ１の表示依頼が行われる。この画面Ｂ１において，ユーザの操作によりイベントが発生すると，イベント登録に応じたイベント振り分け処理が行われ，イベント登録の際に登録されたアプリケーション２のイベントハンドラ２１にイベント発生が通知される。イベントハンドラ２１は，発生したイベントの項目に応じた処理を実行する。
【００１１】
表示画面上にデータ入力されるデータ項目対応の領域を設ける情報処理装置において，各データ項目の属性，データ入力順序，各画面ごとのデータ入力可能なデータ項目など，項目定義情報の変更による画面処理プログラムの修正をなくすことを目的とした技術として，例えば特許文献１に記載されている技術がある。この特許文献１に記載された技術では，画面項目定義として複数の画面に共通するデータ項目を定義し，画面処理プログラムは，その画面項目定義を参照してデータ入力の有無や項目値の属性等のチェックを行うようにしている。この技術は，データ項目の部品化を可能としているが，表示画面自体の一部分の部品化，共通化を図った技術ではなく，画面を重ね合わせることなどは考慮されていない。
【特許文献１】特開平１０−２０７６９９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明は，共通部分が存在する複数の画面の定義情報を画面単位で作成した場合に，画面定義情報の画面資産が冗長に増えてしまうという問題を解決し，画面資産の最適化を実現すること，また，既存の画面資産を利用するアプリケーションに処理の負担が増えることがないようにすること，また，イベントドリブンに関してアプリケーションに性能の劣化が生じないようにすることを目的とする。
【００１３】
すなわち，本発明は，画面を利用して入出力を行う画面制御を用いるアプリケーションを，実際のデータ処理を行うアプリケーション部分と画面制御部とに分離し，画面からのイベント通知によりアプリケーションを動作させる制御方式において，画面資産の最適化を図り，かつ開発コストおよびメンテナンスコストの低減化を実現することを課題とする。
【課題を解決するための手段】
【００１４】
本発明は，上記課題を解決するため，画面を出力し，画面上で発生したイベントに対するデータ処理を行うイベントドリブン型アプリケーションから要求された画面制御を行う画面制御装置であって，それぞれ異なる画面名を有する複数の画面を重ね合わせ，一つの画面名が付与された一つの画面を構成することを示す画面構成定義情報を記憶する画面構成定義情報記憶手段と，イベントドリブン型アプリケーションからの前記一つの画面名を指定した画面生成要求に対し，画面構成定義情報記憶手段を参照し，あらかじめ登録された複数の画面を重ね合わせることにより一つの画面を生成する画面生成手段と，イベントドリブン型アプリケーションからの前記一つの画面へのイベント登録要求に対し，画面構成定義情報記憶手段を参照することにより，登録対象の画面が複数の画面を重ね合わせた画面であるかどうかを判別し，複数の画面を重ね合わせたものである場合には，その複数の画面のそれぞれに属する要求されたイベントを登録するイベント登録手段と，イベント登録手段によって登録したイベントが，重ね合わせた複数の画面の一つで発生した場合に，イベントの発生元の画面名を前記重ね合わせた複数の画面によって構成される一つの画面の画面名に変更してイベントドリブン型アプリケーションに通知するイベント通知手段とを備えることを第１の特徴とする。
【００１５】
これにより，イベントドリブン型アプリケーションが扱う画面を，複数の画面を組み合わせた一つの物理画面とすることができ，アプリケーションは，複数の画面を意識しないで１つの画面としてデータ処理を実行することができるようになる。一つの物理画面を複数の画面を結合して構成することができることから，画面上の一部の領域だけが異なる画面が多数存在した場合に，同一の領域部分を別画面として定義し，多数の画面でその別画面として定義された部分を共通に利用することができるようになり，全体として画面の資産を少なくすることができる。また，アプリケーションは，一つの物理画面だけに着目してイベントに対する処理を行えばよいので，処理負担が増えることはない。
【００１６】
また，上記本発明において，画面構成定義情報記憶手段が記憶する画面構成定義情報が，少なくともイベントドリブン型アプリケーションが指定する画面名と，画面を重ね合わせるときの台紙となるベース画面の画面名と，ベース画面に重ね合わせる１または複数の画面のそれぞれの重ね合わせ画面名と，ベース画面に重ね合わせる１または複数の画面のそれぞれのベース画面上における重ね合わせの位置を示す情報とを含むようにすることを第２の特徴とする。
【００１７】
このように構成すれば，基本となるベース画面とそれに重ね合わせる画面の管理を容易に行うことができるようになる。
【００１８】
さらに，上記本発明において，画面生成手段は，ベース画面に重ね合わせる１または複数の画面のそれぞれの背景色を透明に設定することを第３の特徴とする。
【００１９】
このように構成すれば，ベース画面の一部分が重ね合わせ画面の背景色によって部分的に塗りつぶされることを防ぐことができ，画面デザイン上の不整合が生じないようにすることができる。
【発明の効果】
【００２０】
本発明によれば，複数の画面において，同一の領域を共通化した別画面として扱うことにより，画面の定義数が冗長に増えることがないので，画面定義を含めたアプリケーションの開発コスト，資産管理コストの削減が可能になる。また，画面における共通部分を別定義にすることにより，メンテナンス性が向上する。さらに，本発明は，ベースとなる画面とそれに重ね合わせる共通部分の画面とを別画面としても，イベント通知においては，アプリケーションに複数の画面を意識させないで，一つの画面に見せる仕組みを設けたので，アプリケーションの処理の負担が最初から一つの画面の場合と比較して増加することがなく，性能の劣化も発生しないという効果がある。
【発明を実施するための最良の形態】
【００２１】
以下，本発明の実施の形態を図面を用いながら詳細に説明する。図１は，本発明の構成例を示すブロック図である。図中，１はＣＰＵおよびメモリ等からなるデータ処理装置，２は画面を通して入出力を行い，データを処理するアプリケーション（プログラム），１０は本発明に係る画面制御を行う画面制御部，１１は画面構成定義に従って画面を生成する画面生成部，１２は生成された画面に対しイベントを登録するイベント登録部，１３は画面上のユーザ操作によってイベントが発生したときにアプリケーション２にイベントを通知するイベント通知部，１４は画面構成定義情報を記憶する画面構成定義情報記憶部，３は画面の表示制御および画面上でのイベントの発生を検出する画面入出力制御部，４は画面を表示する表示装置，５はキーボードやマウス等の入力装置である。
【００２２】
アプリケーション２および画面制御部１０が，例えばＪａｖａ言語で記述される場合，画面入出力制御部３は，それらを実行制御する機能を持つＪａｖａの制御プログラムの一部であり，既存のものである。
【００２３】
図２は，本発明の概要を説明するための図である。例えば，アプリケーション２が，図２（Ａ）に示す××検索画面と，図２（Ｂ）に示す△△検索画面の二つの画面を用いるとする。これらの画面は似た内容であり，特に画面下部の条件結果出力の領域は同一である。従来の技術では，ＧＵＩエディタ等を用いて，××検索画面と△△検索画面のそれぞれについて，個別に画面定義およびイベントに対する処理ロジックを記載していた。なお，昨今のＧＵＩエディタでは，ＧＵＩ部品をフォームに貼り付ければ，その部品に対する制御の記載も完了するものがあり，ここでの画面定義は一般の定義だけでなく，画面に特化した部品ロジックも含んだ情報を意味する。
【００２４】
このような従来の方法では，画面ごとに個別に設計が行われ，条件結果出力の領域のようにまったく同様であったとしても，共通化は図られていなかった。結果として画面資産が冗長となり，メンテナビリティも低下する結果となっていた。
【００２５】
これに対し，本発明では，以下に詳しく説明するように，（１）共通部分の別画面化，（２）別画面を重ね合わせて一つの画面を生成，（３）イベント通知の統一化，によって，従来技術の問題点を解決する。
【００２６】
（１）共通部分の別画面化
本発明による共通部分の別画面化について説明する。本発明では，例えば図２（Ｃ）に示すように，××検索画面と△△検索画面において，画面上まったく同一の領域（条件結果出力部分）を，共通化した別画面として定義する。この例では，条件結果画面として定義している。これにより，××検索画面と△△検索画面における定義数は減少することになる。
【００２７】
なお，共通化した画面は，背景色を透明にし，表示のときには結合して重ね合わせるようにする。これにより共通化した画面は，ベースとなる業務固有の画面のレイアウトや背景色に依存しなくなる。共通画面である条件結果画面の背景色が透明であれば，例えば図２（Ｄ）に示す□□検索画面のように，ベースとなる画面にメニューバー等が存在するようなケースでも，重なった部分が共通画面によって塗りつぶされてしまうようなことはない。また，重ね合わせる条件結果画面の位置を事前に設定可能になっているので，これによっても，重ね合わせによるベース画面上の情報の欠落を防ぐことができる。
【００２８】
（２）別画面を重ね合わせて一つの画面を生成
アプリケーションの実行時に画面を生成し表示する際には，ベースとなる××検索画面や△△検索画面に，条件結果画面の共通画面の定義を重ね合わせ，一つの業務画面を構成する。このため，重ね合わせの定義情報を管理する画面構成定義情報を用意しておく。
【００２９】
図３は，画面構成定義情報テーブルの例を示す。この画面構成定義情報テーブルは，図１の画面構成定義情報記憶部１４に画面構成定義情報ファイル１４０として記憶される。画面構成定義情報ファイル１４０のファイル名は，あらかじめ固定的に定めたファイル名としてもよく，また，アプリケーション２の環境設定情報として事前に登録されたファイル名などであってもよい。
【００３０】
この画面構成定義情報テーブルにおける業務画面名は，複数の画面を重ね合わせることにより構成される画面の論理名である。ベース業務画面名は，重ね合わせの台紙（ベース）となる業務画面名である。重ね合わせ画面名は，ベース業務画面上に重ねる業務画面名である。この重ね合わせ画面名は，一つの業務画面名に対して複数の業務画面を定義することができる。図３の例では，☆☆検索結果画面に対して，条件結果画面と結果補足画面の二つの重ね合わせ画面名が定義されている。なお，各画面のサイズ，属性等は，画面定義情報として別に記憶されている。個別の画面定義情報については従来技術と同様であるので，ここでの詳しい説明は省略する。
【００３１】
画面構成定義情報テーブル中の開始位置および終了位置は，重ね合わせ画面名をベース業務画面上に重ねるときのベース業務画面の表示位置からの重ね合わせの相対位置を示し，ピクセルの座標位置で指定される。開始位置が重ね合わせる画面領域の左上のピクセル位置を示すのに対し，終了位置は重ね合わせる画面領域の右下のピクセル位置を示す。
【００３２】
図４に，画面構成定義情報に基づく画面構成の例を示す。例えば，図３の画面構成定義情報テーブルによって定義された××検索結果画面は，条件結果画面の重ね合わせ画面が結合されて，図４（Ａ）に示すように構成される。なお，△△検索結果画面も同様に定義され，類似画面の共通化が図られている。
【００３３】
同様に，□□検索結果画面は，条件結果画面の重ね合わせ画面が結合されて，図４（Ｂ）に示すように構成される。□□検索結果画面のベースとなる□□検索画面では，左端にメニュー領域が設けられているため，重ね合わせの開始位置が異なる位置に定義されている。
【００３４】
☆☆検索結果画面は，条件結果画面と結果補足画面の二つの画面が重ね合わされて，図４（Ｃ）に示すように構成される。このように複数の重ね合わせ画面を貼り付けることにより，共通化を図ることも可能である。
【００３５】
画面構成定義情報テーブルにおける業務画面名または重ね合わせ画面名に，重ね合わせ済みの画面を指定することもできる。これにより，画面資産のさらなる共通化が可能である。図５にその例を示す。図５の例では，ベース業務画面および重ね合わせ画面に，重ね合わせ済み業務画面が指定されており，これによって更なる重ね合わせ済み画面が生成されている。
【００３６】
図６は，他の画面表示例を示している。前述したように，重ね合わせ画面の背景色は透明化されている。したがって，ベース業務画面の重ね合わせ領域に，文字等が記載されているとき，それが図６に示すように部分的に見えることになる。
【００３７】
（３）イベント通知の統一化（アプリケーション制御互換）
前述した画面構成定義情報により，複数の画面定義を組み合わせて一つの画面を構成することにより，物理的に１枚の画面に見せることが可能であるが，そのままでは，アプリケーション２が実装上，複数の画面を制御する必要がある。
【００３８】
図７に従って，複数の画面を重ね合わせることによって生じるアプリケーション２への影響について説明する。図７（Ａ）の××検索結果画面のように，従来の重ね合わせのない画面構成の場合には，アプリケーション２は，１枚の画面に対して単純に画面生成およびイベント登録の処理を行えばよい。イベント登録は，ユーザによる画面上の項目操作等のイベント条件を，画面入出力制御部３がアプリケーション２等に通知できるようにするための事前の登録処理である。イベント通知は，登録されたイベント条件が発生したときに，それを処理するアプリケーション２等にイベントの発生を知らせる処理である。ここでは，イベント通知に対してアプリケーション２により項目操作が行われている。ここでの項目操作は，アプリケーション２により表示文字等を設定する制御の依頼である。このように，画面定義と表示画面とが１対１に対応している場合には，アプリケーション２は，画面ごとに画面生成およびイベント登録の処理の依頼を行って簡単に処理することができる。
【００３９】
しかし，重ね合わせ済み画面を直接アプリケーション２が制御する場合には，次のような問題が発生する。例えば，図７（Ｂ）に示すように，××検索結果画面が，××検索画面をベースとして，それに条件結果画面を重ね合わせた画面であったとする。この場合，アプリケーション２は，××検索画面制御，条件結果画面制御のそれぞれを意識して，全体の画面制御に関する処理を行う必要が生じる。具体的には××検索画面に対するイベント登録処理，条件結果画面に対するイベント登録処理等，個別の画面ごとに画面の表示制御およびイベント登録の処理を行うことが必要になる。このように，画面を重ねることにより，アプリケーション２の処理ロジックとして，複数の画面に対するイベント制御や項目制御を実装しなければならなくなるので，アプリケーション２の画面制御が，図７（Ａ）のような１枚だけの画面構成の場合に比べて複雑化し，画面を共通化したことによる処理規模の悪化，性能の劣化が生じることになる。
【００４０】
そこで，本発明では，図８に示すように，重ね合わせ済み画面であっても，アプリケーション２には重ね合わせなしの１枚の画面であるかのように見えるための仕組みを，画面制御部１０内に設ける。アプリケーション２は，例えば××検索結果画面が，××検索画面に条件結果画面を重ね合わせた画面であったとしても，図７（Ａ）の重ね合わせなしの××検索結果画面の場合と同様に，１枚の××検索結果画面だけを，画面生成，イベント登録または項目操作の際に指定すればよく，これに対して画面制御部１０内で，重ね合わせに伴う画面生成，表示およびイベント通知先等の画面制御の互換性を実現する。
【００４１】
例えば，××検索画面には，イベント登録対象の項目として項目ａがあり，条件結果画面にはイベント登録対象の項目として項目ｃ，ｄがあったとしても，アプリケーション２には，項目ａ，ｃ，ｄのすべてが１枚の××検索結果画面の項目として扱うことができるようにする。このため，画面制御部１０は，アプリケーション２から××検索結果画面に対するイベント登録依頼があると，画面入出力制御部３に対し，××検索画面についての項目ａのイベント登録，また，条件結果画面についての項目ｃ，ｄのイベント登録をそれぞれ行う。
【００４２】
図９は，画面制御部１０が行うイベント登録処理の例を示している。ここでは，前述した××検索画面がパネルＡ，条件結果画面がパネルＢとして示されている。画面制御部１０は，アプリケーション２からのイベント登録処理の依頼があると，重ね合わせるすべてのパネルに対して，図９に示すようにイベント登録を行う。パネルＡとパネルＢとが重ね合わされることによって１枚の画面として扱われるべきものであるかどうかは，図３で示した画面構成定義情報テーブルによって容易に判別することができる。すなわち，アプリケーション２が，例えば業務画面名として××検索結果画面を指定すれば，画面制御部１０は，画面構成定義情報テーブルを参照することにより，その画面が××検索画面のベース業務画面と条件結果画面の重ね合わせ画面とから構成されるものであることを判別して，それぞれに対するイベント登録処理を行う。
【００４３】
図１０は，画面制御部１０が行うイベント通知処理の例を示している。この例では，アプリケーション２が，業務画面名として「Ａ０」を指定して，それに対するイベント登録依頼を行い，画面制御部１０は，この業務画面Ａ０を構成するパネルＡ，パネルＢに対して，それぞれ項目ａおよび項目ｃ，ｄのイベント登録を行っている。
【００４４】
ここで，パネルＢの項目ｃに対してユーザからのデータ入力等があり，イベントが発生したとする。画面入出力制御部３は，そのイベントを検出し，イベント登録元の画面制御部１０に対し，パネルＢの項目ｃにイベントが発生したことを割込み等によって通知する。画面制御部１０は，イベント発生元のパネルＢが，業務画面Ａ０を構成する画面であることから，イベント発生元のパネルＢを，「Ａ０」の業務画面名に変更して，アプリケーション２にイベント通知を行う。これによって，アプリケーション２は，パネルＡ，パネルＢを区別することなく，業務画面Ａ０だけを考慮した処理を実行できることになる。
【００４５】
図１１は，画面制御部１０における画面生成部１１の画面生成処理フローチャートである。アプリケーション２からの業務画面名を指定した画面生成依頼に対し，画面生成部１１は，最初に画面構成定義情報ファイルを読み込む（ステップＳ１０）。この画面構成定義情報ファイルを参照することにより，画面の生成を依頼された業務画面名に対して，重ね合わせ画面が定義されているかどうかを判別する（ステップＳ１１）。
【００４６】
重ね合わせ画面が定義されていない場合，従来と同様に依頼を受けた画面をそのまま生成する処理を実行し（ステップＳ１２），処理を終了する。
【００４７】
画面構成定義情報ファイルに，重ね合わせ画面が定義されている場合，まず依頼された業務画面名に対応づけられたベース業務画面名を抽出し，その定義情報を読み込むことにより，ベース業務画面を生成する（ステップＳ１３）。その後，画面構成定義情報ファイルに登録された重ね合わせ画面の数だけ，以下のステップＳ１４〜Ｓ１７を繰り返す。
【００４８】
画面構成定義情報ファイルから，依頼された業務画面名に対応づけられた重ね合わせ画面名を抽出し，その定義情報を読み込むことにより，重ね合わせ画面を生成する（ステップＳ１４）。次に，その重ね合わせ画面の背景色を透明に設定する（ステップＳ１５）。その後，ステップＳ１３で生成したベース業務画面上に，重ね合わせ画面を貼り付ける。（ステップＳ１６）。このとき，重ね合わせ画面を貼り付ける位置は，画面構成定義情報ファイルに登録された重ね合わせ画面の開始位置，終了位置に従う。開始位置および終了位置によって定まる画面サイズが，実際の重ね合わせ画面のサイズより小さい場合，例えば重ね合わせ画面からの左上端を基準にした領域の抽出処理，または重ね合わせ画面の縮小処理を行うことにより，サイズを合わせる。以上の処理を画面構成定義情報ファイルに登録された重ね合わせ画面が終了するまで繰り返し，すべての重ね合わせ画面の重ね合わせが終了したならば処理を終了する（ステップＳ１７）。
【００４９】
図１２は，画面制御部１０におけるイベント登録部１２のイベント登録処理フローチャートである。アプリケーション２からの業務画面名と項目を指定したイベント登録依頼に対し，イベント登録部１２は，まず画面構成定義情報ファイルを読み込む（ステップＳ２０）。この画面構成定義情報ファイルを参照することにより，イベントの登録を依頼された業務画面名に対して，重ね合わせ画面が定義されているかどうかを判別する（ステップＳ２１）。
【００５０】
重ね合わせ画面が定義されていない場合，従来と同様に依頼を受けた業務画面にそのままイベントを登録する処理を実行し（ステップＳ２２），処理を終了する。
【００５１】
画面構成定義情報ファイルに，重ね合わせ画面が定義されている場合，まず依頼された業務画面名に対応づけられたベース業務画面名を抽出し，そのベース業務画面に対してイベントを登録する処理を実行する（ステップＳ２３）。すなわち，そのベース業務画面に対してイベントを登録することを画面入出力制御部３に通知する。
【００５２】
次に，画面構成定義情報ファイルから，依頼された業務画面名に対応づけられた重ね合わせ画面名を抽出し，重ね合わせ画面に対してイベントを登録する処理を実行する（ステップＳ２４）。この処理を画面構成定義情報ファイルに登録された重ね合わせ画面が終了するまで繰り返す（ステップＳ２５）。重ね合わせ画面が終了したならば，ステップＳ２３およびステップＳ２４で登録したイベントの通知先の情報をメモリに記憶し，保持する（ステップＳ２６）。イベント通知先情報を保持しておくのは，画面入出力制御部３からのイベント発生の通知があったときに，発生元のパネルをアプリケーション２から指定された業務画面名に変更するためである。
【００５３】
図１３は，画面制御部１０におけるイベント通知部１３のイベント通知処理フローチャートである。画面上でユーザ操作等によりイベントが発生すると，画面入出力制御部３からイベント通知があるので，そのイベント通知を受信する（ステップＳ３０）。イベント通知の発生元情報をもとに，イベント登録時に記憶したイベント通知先情報を参照する（ステップＳ３１）。イベント通知先情報の参照結果から発生元の画面名（パネル名）の変更が必要かどうかを判定する（ステップＳ３２）。
【００５４】
イベント通知先情報として発生元の情報が保持されていない場合，重ね合わせの画面からではない通常の１枚の画面で発生したイベントであるので，次のステップＳ３３の処理をスキップする。イベント通知先情報として発生元の情報が保持されている場合には，イベント発生元を，イベント登録時にアプリケーション２から指定された業務画面名に変更する（ステップＳ３３）。その後，イベントをアプリケーション２へ通知する（ステップＳ３４）。
【００５５】
これによって，アプリケーション２に対し，複数のパネルで発生したイベントを，１枚の業務画面で発生したイベントとして見せることが可能になる。
【００５６】
以上の画面制御部１０の処理は，コンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録して提供することも，ネットワークを通して提供することも可能である。
【００５７】
画面制御部１０のプログラムは，プラットフォームとなるＪａｖａ等（本発明の実施はＪａｖａに限られるわけではない）の制御プログラムである画面入出力制御部３と，実際のデータ処理によって業務を遂行するアプリケーション２との間に存在し，複数のアプリケーション２に対して共通に設けることも，また各アプリケーション２ごとにコンピュータ内にローディングされるようにすることもできる。また，アプリケーション２内に，画面制御部１０を実現するプログラムをアプリケーション２の一部として組み込むことも可能である。
【図面の簡単な説明】
【００５８】
【図１】本発明の構成例を示すブロック図である。
【図２】本発明の概要を説明するための図である。
【図３】画面構成定義情報テーブルの例を示す図である。
【図４】画面構成定義情報に基づく画面構成の例を示す図である。
【図５】重ね合わせ画面の表示例を示す図である。
【図６】他の重ね合わせ画面の表示例を示す図である。
【図７】複数の画面を重ね合わせることによって生じるアプリケーションへの影響を説明するための図である。
【図８】画面制御部によるイベント登録および通知の処理を説明する図である。
【図９】イベント登録処理の概要を示す図である。
【図１０】イベント通知処理の概要を示す図である。
【図１１】画面生成部の画面生成処理フローチャートである。
【図１２】イベント登録部のイベント登録処理フローチャートである。
【図１３】イベント通知部のイベント通知処理フローチャートである。
【図１４】従来技術を説明するための図である。
【図１５】従来技術を説明するための図である。
【図１６】従来技術を説明するための図である。
【図１７】従来技術を説明するための図である。
【符号の説明】
【００５９】
１    データ処理装置
２    アプリケーション
３    画面入出力制御部
４    表示装置
５    入力装置
１０  画面制御部
１１  画面生成部
１２  イベント登録部
１３  イベント通知部
１４  画面構成定義情報記憶部
１４０  画面構成定義情報ファイル
【図１】
0004758253.tif 000002
【図２】
0004758253.tif 000003
【図３】
0004758253.tif 000004
【図４】
0004758253.tif 000005
【図５】
0004758253.tif 000006
【図６】
0004758253.tif 000007
【図７】
0004758253.tif 000008
【図８】
0004758253.tif 000009
【図９】
0004758253.tif 000010
【図１０】
0004758253.tif 000011
【図１１】
0004758253.tif 000012
【図１２】
0004758253.tif 000013
【図１３】
0004758253.tif 000014
【図１４】
0004758253.tif 000015
【図１５】
0004758253.tif 000016
【図１６】
0004758253.tif 000017
【図１７】
0004758253.tif 000018