JPH0997158A

JPH0997158A - 画面遷移の制御方法

Info

Publication number: JPH0997158A
Application number: JP7253716A
Authority: JP
Inventors: Yuichi Takahashi; 祐一高橋
Original assignee: Sanyo Electric Co Ltd
Current assignee: Sanyo Electric Co Ltd
Priority date: 1995-09-29
Filing date: 1995-09-29
Publication date: 1997-04-08

Abstract

(57)【要約】【課題】ウインドウシステムにおいて画面のリソース
生成に時間が掛かり、プログラム起動やＩ／Ｏの応答性
が悪い。【解決手段】複数の画面を用意し、それらを切り替え
てユーザと対話的に処理を進める情報処理装置であっ
て、前記画面の表示に際して、該画面のリソースの生成
と該リソースの表示とを分離して行いうる同装置におい
て、前記画面相互の遷移方向を画面フローダイアグラム
として定義しておき、ひとつの画面を表示したとき、前
記ダイアグラムによって当該画面と直接結び付けられた
画面を決定し、次にそれらの画面についてのみあらかじ
めリソースを生成する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】多数の入力画面を用意し、それら
を切り替えながらユーザが必要な情報を入力するように
なした情報処理装置に関する。

【０００２】

【従来の技術】情報処理を行う場合、情報処理装置は、
ユーザに対して必要な情報の入力を促すために、入力用
画面あるいはダイアログボックスを表示し、ユーザから
の入力を待つようにしている。また、対話的に処理を進
めるために入力画面を複数用意し、ユーザが画面を切り
替えながら、その画面、画面において要求されている情
報を入力していくのが普通である。

【０００３】そして、この情報処理を行う画面は、一般
に階層的な性質を持っている。即ち、図１は画面の移り
替わりの関係を示したものであるが、例えば画面１から
は、ユーザの指示により、画面１.2さらに画面１.2.1乃
至１.2.3へと遷移することを示している。そして、画面
１.2から画面１.1へ遷移したい場合には、ユーザは、一
旦画面１に戻してから画面１.1に移る必要があることを
示している。このように、情報処理装置においては、そ
の画面の移り替わりに階層的な関係があり、それを図１
のように表わすことができるのである。

【０００４】ところで、Ｘ−Ｗｉｎｄｏｗシステムなど
の標準的なウィンドウシステムでは、ウィンドウが動作
の基本単位となり、各アプリケーションプログラムは、
物理画面上に重複して設定可能なウィンドウを使って、
ユーザと対話するようになっている。また、特にユーザ
からの入力を受け付ける為に、ダイアログボックスと呼
ぶ入力画面の一種をウインドウ内に表示し、そのダイア
ログボックスを経由して、アプリケーションプログラム
はユーザからの入力データを取り込むこともある。

【０００５】Ｘ−Ｗｉｎｄｏｗシステムにあっては、こ
のダイアログボックスはインスタンスの集合として表わ
される。インスタンスは視覚的に見えるグラフィカル・
ユーザ・インターフェース（ＧＵＩ）ひとつ、例えばボ
タンひとつに対してひとつ存在する構造体である。イン
スタンスは、それが表わすＧＵＩのリソース、即ち、配
置や大きさや色を定義していて、それぞれのインスタン
スは、視覚的に最も下層となるインスタンスから順に、
その階層関係に従って上下左右にポインタで接続されて
いる。

【０００６】尚、ここでは、このインスタンスの集合体
を便宜的にダイアログボックス又は画面と呼ぶことにす
る。そして、ある機能を持った一連のコードの中の関数
が、ある画面のベースとなるインスタンスをパラメータ
として呼び出されて、動作するのである。

【０００７】ここで、ひとつのダイアログボックスをウ
インドウ内に表示するためには、先ず、関数realize()
を使用して描画に必要なリソースを作り出さなければな
らない。

【０００８】関数realize() は、インスタンスのメンバ
を参照してカラーPixcel値を決定し、指定されているフ
ォントをロードし、サイズに合わせたウインドウを作成
する。そして、多くの場合、ビットマップにＧＵＩの絵
や文字を描画する。これは、ビットマップを基本にした
方が表示速度が向上するからである。また、関数realiz
e()は、ポインタで結ばれた同一レベルのインスタン
ス、さらに、下位のインスタンスが存在すれば、その全
レコードに対して同様に処理してダイアログボックスの
リソースを作り出す。

【０００９】ただし、関数realize() は表示のためのリ
ソースを生成するだけであり、実際にそれを表示するに
は、関数map()を使用する。関数map()は同一レベル及び
下位レベルのインスタンスを次々に表示し、サーバのイ
ベントを受け付けることが出来るようにする。通常クラ
イアント側には、送られてきたイベントに応じてウイン
ドウの内容、即ち画面あるいはダイアログボックスを表
示するようなコードが記述されているので、結果として
ウインドウにダイアログボックスが表示される。

【００１０】

【発明が解決しようとする課題】図４は、アプリケーシ
ョンプログラムの先頭部分における一般的な記述の例を
示す。初期設定として関数realize(Null,0) を呼び出す
と、同関数は、当該ロードモジュール内に定義されてい
るすべての画面あるいはダイアログボックスについて、
前述した手順によりリソースを生成する。その際、生成
したリソースはアプリケーションが管理するメモリに記
憶するが、メモリが不足した場合、残りのリソースは補
助記憶装置、例えばハードディスクに記憶する。

【００１１】このように、アプリケーションプログラム
の起動時にすべての画面のリソースを生成する場合、多
数の画面を切り替えて処理を進めるようなプログラムで
は、最初にリソース生成の為の時間が掛かってしまい、
起動に要する時間が長くなってしまっていた。また、リ
ソースが大量の場合、メモリ上に存在しないリソースが
多くなる為、画面を切り替えた時にメモリとハードディ
スクとの間でスワッピングが発生する頻度が高くなり、
その結果、画面の切り替えが遅くなる弊害も生じてい
た。

【００１２】

【課題を解決するための手段】本発明は、複数の画面を
用意し、それらを切り替えてユーザと対話的に処理を進
める情報処理装置であって、前記画面の表示に際して、
該画面のリソースの生成と該リソースの表示とを分離し
て行いうる同装置において、前記画面の遷移関係を表わ
す画面フローテーブルを定義しておき、ひとつの画面を
表示したとき、前記フローテーブルを参照して当該画面
に直接関係付けられた画面を決定し、次にそれらの又は
その画面についてのみリソースを生成することにより、
上記課題を解決するものである。

【００１３】

【作用】本発明では、複数の画面を切り替えて処理を進
める情報処理装置において、ある画面に切り替わったと
き、その画面から直接遷移する画面を画面フローテーブ
ルを参照して決定し、それらの画面についてのみ画面の
リソースを生成する。そして、ユーザによって次の画面
への切り替わりが指示されたとき、生成済みのリソース
を使って画面を表示する。

【００１４】

【実施例】図１は、実施例の情報処理装置が用意してい
る画面とその階層関係を示す図である。実施例装置では
先ず画面１を表示し、ユーザの指示あるいは入力に応じ
て、画面1.1又は画面1.2に表示を切り替えて新たな情報
を提供するとともに、ユーザに対して次の指示あるいは
入力を促すのである。

【００１５】画面1.1からは、それより下層に結び付け
られた画面が無いので、画面１に戻るしかない。一方、
画面1.2には、その下層に画面1.2.1乃至1.2.3が存在
し、ユーザの指示や入力に応じて、画面1.2から画面1.
2.1、画面1.2.2又は画面1.2.3へと遷移することも出来
るし、あるいは逆に、画面１に戻ることも出来る。

【００１６】そして、画面1.2.1乃至1.2.3には、図から
わかるように、それより下層に画面が存在しないので、
上層の画面つまり画面1.2に戻ることになるが、本実施
例では特に、画面1.2.1からは直接画面１に戻るように
なっている。

【００１７】その画面遷移の方向をわかりやすく示した
のが図２の画面フローダイアグラムである。画面１から
は画面1.2を経由して画面1.2.1に達するが、そこからは
画面1.2を経ずに画面１に遷移することがわかる。しか
し、画面1.2.1はあくまで画面1.2の下層にあり、画面１
からは直接画面1.2.1に遷移することが出来ないことが
図からわかる。

【００１８】図３は、図２に示す画面相互の遷移の関係
を記述した遷移テーブル30である。同テーブル30におい
て、左側に「現在の画面」として実施例装置に用意され
た６つの画面があり、それぞれの画面から図２において
矢印で結び付けられた画面が右側の「遷移先の画面」に
すべて定義されている。つまり、例えば、現在の画面が
画面１ならば、そこから遷移する先の画面が画面1.1と
画面1.2であることがわかるし、また、例えば、現在の
画面が画面1.2.1であれば、遷移する先が画面１だけで
あることが、遷移テーブル30から読み取れるのである。

【００１９】そして、本実施例では、アプリケーション
プログラムを図５のように記述する。即ち、最初に表示
する画面１に係わるプログラムでは、先ず、画面１を表
示するために画面１を引数として関数realize("画面
１",0) を呼び出し、画面１だけのリソースを生成す
る。そして、すぐに関数map("画面１",0)を呼び出して
そのリソース、即ち、画面１を表示する。

【００２０】通常はこの後、引き続いて画面１に係わる
入出力処理を記述するが、本実施例では、その前に、現
在の画面と結び付いた画面を遷移テーブル30を参照して
決定し、その画面のリソースを生成する。この場合、画
面１からは画面1.1と画面1.2に遷移することが遷移テー
ブル30からわかるので、その２つの画面のリソースを関
数realize() を呼び出して生成する。

【００２１】これは、計算機内部の処理に比較して人間
の入力操作が極めて遅いので、画面１を表示してから実
際の入力があるまで、計算機が何も仕事をしない時間が
生じていたところ、その時間を利用して、次に表示され
るであろう画面のリソースを、あらかじめ生成しておく
ものである。しかし、この段階ではリソースを生成する
のみで、それを表示する関数map()を呼び出すことはな
い。しかも、リソースを生成するのは、遷移テーブル30
において現在の画面と直接結び付けられている画面だけ
である。

【００２２】しかる後、画面１に係わるユーザからの指
示や入力を受け付けることが出来るように、実際の処理
を記述しておくのである。そして、例えば、ユーザの指
示により画面1.2に遷移する場合は、画面1.2とは直接結
び付きの無い現在生成済みのリソースを破棄してから、
遷移するようにしている。具体的には、遷移テーブル30
を参照して、遷移先の画面1.2 と、それに結び付けられ
た画面１及び画面1.2.1乃至1.2.3の５つの画面と、現在
生成済みのリソースとを比較し、この５つの画面に含ま
れないリソースを決定して、そのリソース、この場合、
画面1.1 のリソースを関数destroy("画面1.1")を呼び出
して破棄するようにしている。これにより、不要なリソ
ースがメモリを占有することを減らし、ひいては、メモ
リとハードディスクとの間で発生するスワッピングの回
数を最少にする。

【００２３】その後、画面1.2 に係わる処理を実行する
プログラムに移行すると、図示はしていないが、そこで
は、既に画面1.2のリソースが生成されているので、関
数map("画面1.2",0)を呼び出すだけで直ちに画面1.2を
表示できる。

【００２４】そして、前述した処理と同様に、画面1.2
に係わる入出力処理を記述する前に、現在の画面と結び
付いた画面を遷移テーブル30を参照して決定し、その画
面のリソースを生成する。この場合は、画面1.2 からは
画面1.2.1乃至1.2.3に遷移することがわかるので、その
３つの画面のリソースを関数realize() を呼び出して生
成するのである。そうしておいてから、画面1.2 に固有
の入出力処理を記述する。

【００２５】以上の処理をフローチャートにまとめると
図６のようになる。各々の画面に係わるプログラムは、
最初に当該画面のリソースを表示するのであるが（ステ
ップS603）、その前に当該画面のリソースが既に生成さ
れているか否かを確認し（同S601）、無い場合にリソー
スを生成する（同S602）ようにするとよい。

【００２６】次に、当該画面と結び付きのある画面を遷
移テーブル30を参照して決定し（同S604）、それらの画
面のリソースを生成する（同S605）。もちろんここで
は、既に説明したようにリソースを生成するのみで、そ
れを表示することはない。

【００２７】その後、当該画面に係わる指示や入力を処
理し（同S606）、次の画面に遷移するとき（同S607;Ye
s）、遷移テーブル30を参照して遷移先の画面において
関係のなくなるリソースを決定する（同S608）。そし
て、不要になるリソースがあれば（同S609;Yes）、それ
らのリソースを破棄（同S610）してから、遷移先の画面
に係わるプログラムに移行する（同S611）。

【００２８】こうすることで、遷移先のプログラムで
は、当該画面のリソースをいきなり表示することが出来
るので、ユーザから見て画面切替の応答速度が速くな
る。しかも、そのリソースは、画面表示してからユーザ
が入力応答するまでの待ち時間を利用して生成するの
で、ステップＳ６０６の入出力処理に影響を与えること
もない。

【００２９】

【発明の効果】本発明によれば、現在表示している画面
に直接結び付いている画面のリソースをあらかじめ生成
しておくので、画面の切り替えに際して応答時間が速く
なる。

【００３０】また、プログラムの起動時に全画面のリソ
ースを一括して生成する従来の方法とは違い、直近に必
要になる画面のリソースのみ生成するので、プログラム
の起動に要する時間を最少に出来る。しかも、不要なリ
ソースがメモリを占有することがないので、メモリとハ
ードディスクとの間の冗長なスワッピングを減少し、そ
れによって、快適な応答性を実現出来る。

【図面の簡単な説明】

【図１】実施例装置が有する画面の階層関係を示す図で
ある。

【図２】実施例装置が有する画面相互の遷移の方向を示
す画面フローダイアグラムである。

【図３】画面相互の遷移の関係を記述した遷移テーブル
である。

【図４】従来のプログラムの一般的な記述例を示す図で
ある。

【図５】実施例プログラムの記述例を示す図である。

【図６】実施例の処理手順を示す図である。

【符号の説明】

３０遷移テーブル

Claims

【特許請求の範囲】

【請求項１】複数の画面を用意し、それらを切り替え
てユーザと対話的に処理を進める情報処理装置であっ
て、前記画面の表示に際して、該画面のリソースの生成
と該リソースの表示とを分離して行いうる同装置におい
て、前記画面相互の遷移方向を画面フローダイアグラムとし
て定義しておき、ひとつの画面を表示したとき、前記ダ
イアグラムによって当該画面と直接結び付けられた画面
を決定し、次にそれらの又はその画面についてのみあら
かじめリソースを生成するようになしたことを特徴とす
る画面遷移の制御方法。
【請求項２】複数の画面を用意し、それらを切り替え
てユーザと対話的に処理を進める情報処理装置であっ
て、前記画面の表示に際して、該画面のリソースの生成
と該リソースの表示とを分離して行いうる同装置におい
て、前記画面の遷移関係を表わす画面フローテーブルを定義
しておき、ひとつの画面を表示したとき、前記画面フロ
ーテーブルを参照して当該画面に直接関係付けられた画
面を決定し、次にそれらの又はその画面についてのみあ
らかじめリソースを生成するようになしたことを特徴と
する画面遷移の制御方法。
【請求項３】前記生成されたリソースのうち、画面の
遷移に伴って遷移先の画面との直接の遷移関係がなくな
った画面のリソースを、順次破棄することを特徴とする
請求項１又は２記載の画面遷移の制御方法。