JPH0749758A

JPH0749758A - ウィンドウ設計及び入力装置

Info

Publication number: JPH0749758A
Application number: JP5196402A
Authority: JP
Inventors: Mikito Sugano; 幹人菅野; Reiko Moriyama; 令子森山
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 1993-08-06
Filing date: 1993-08-06
Publication date: 1995-02-21

Abstract

(57)【要約】【目的】プログラム作成の負荷量を減らし、また端末
ホスト間の通信量を減らしたウィンドウ設計・入力装置
を得る。【構成】ウィンドウ構成部品を選択し位置・大きさを
指定する設計部と、構成部品の情報を部品情報リストと
してファイルに管理する部品管理部と、外部からのトリ
ガで部品情報を読み書きするファイルＩ／Ｏ管理部とか
らなるウィンドウ生成手段を備えて、このウィンドウ生
成手段で生成された画面単位でウィンドウファイルを用
意するようにした。またウィンドウをオープン・クロー
ズする参照部と、入力データの種類または範囲または長
さを検査するチェック部と、入力データに記号を付加し
編集する編集部とを付加したウィンドウサーバを備え、
ホストの指示で管理されているウィンドウファイルを読
み出し、サーバが入力データをチェック・編集して後、
ホストにデータを伝送するようにした。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明はホストコンピュータで
のプログラム作成の負荷を減らした分散処理ウィンドウ
設計装置とウィンドウ入力装置に関するものである。

【０００２】

【従来の技術】従来のウィンドウ・システムでは、各種
の処理は端末側のサーバとホスト側のクライアントの２
つのプログラムが分担して行っている。その分担は、サ
ーバがウィンドウを生成し、画面上に表示させ、または
図形等を出力し、またキーボードやマウスからの入力を
処理する。こうしてサーバは直接デバイスへのアクセス
を担当する。一方、クライアントはウィンドウの生成を
要求（リクエスト）したり、データの入力を要求する
が、これらはプロトコルという形態でサーバに転送さ
れ、このプロトコルを受けたサーバはクライアントの要
求に従ってウィンドウを表示したり消したりする。更
に、キーボード入力やマウスの動作はサーバに検知さ
れ、プロトコル（イベント、リプライ）としてクライア
ントに転送される。クライアントは伝送されたイベント
から次のアクションをプロトコル（リクエスト）として
サーバに伝える。これを繰り返して、最終的に必要なウ
ィンドウ上の入力データがホストに細切れに伝送されて
ホストがチェック・編集してホストで入力となる。

【０００３】上記のことは実際の入力時だけでなく、入
力用の画面設計やプログラム作成時にも同様の機能分担
をする。即ちデバイスとのインターフェースはサーバが
受け持つが、画面上の表示の種類、大きさ、意味、制限
等はクライアントが指示しなければならない。つまり、
クライアント側のユーザプログラム作製者が詳しくサー
バの機能、動作を知っていなければならないし、またプ
ログラム作成に多大の労力と時間を要する。図１４は日
刊工業新聞社Ｘ−ＷｉｎｄｏｗＶｅｒ．１１プログラ
ミングに記述されているＸウィンドウシステムの構成
図、つまり、従来のウィンドウを使用したシステムにお
いて、画面設計、プログラミングについて説明するため
の構成図である。図１７において７３はウィンドウサー
バ、７２はウィンドウサーバを駆動する命令の集合のラ
イブラリである。７４はウィンドウサーバが動作するた
めの計算機であり、７１はライブラリが実行プログラム
にリンクされて動作するクライアントプログラムであ
る。

【０００４】図１４のような形式のウィンドウシステム
では、実際の画面の制御は全てウィンドウサーバが行
い、ライブラリを使って作成するクライアントプログラ
ムはウィンドウサーバに対して画面を作ったり、図形を
書いたりする要求だけを行う。ウィンドウサーバは要求
を受け付けると実際にその要求を処理し、適切な返答を
行ったり、エラーを返したりする。ウィンドウサーバは
その他にイベントの処理を行う。イベントはマウスカー
ソルの移動ボタンがクリックされるようなイベントやウ
ィンドウの位置、サイズが変更されたなどの情報をクラ
イアントプログラムに知らせる。こうしてイベントに応
じたデータが通信路を通じてクライアントプログラムに
渡されていた。クライアントプログラムはこれらのイベ
ントを適切に処理することで実行を行っていく。従っ
て、クライアントプログラムは全てのイベントに応じた
内部ロジックが必要であり、プログラムの開発が大規模
になる場合が多い。

【０００５】一方、入力、出力の区別などは部品毎に内
部ロジックがクライアントプログラム中にライブラリを
用いて記述する必要があり、例えば、画面設計をする
際、トリガ用のボタンを画面上の所定の位置に設けよう
とすると、ホストのクライアントプログラムで、ＣｒｅａｔｅＢｏｔｔｏｎ（Ｘ，Ｙ，ｗｉｄｔｈ，ｈ
ｅｉｇｈｔ）また入力用のフレーム面を所定の位置に設けようとする
と、ＣｒｅａｔｅＦｒａｍｅ（Ｘ，Ｙ，ｗｉｄｔｈ，ｈｅ
ｉｇｈｔ）と記述する必要があった。あるテキストを入力エリアで
扱う時と出力エリアで扱う時は、クライアントプログラ
ムの内部ロジックで書き分けて、その動作を変える必要
がある。このような処理を書き分けることは木目細かい
処理を行いたい場合には有効な手法であるが、用途が限
定されたウィンドウ部品を使って処理を行いたい場合に
は、開発が複雑となる弊害がある。

【０００６】更にこれらのウィンドウの設計は、クライ
アントプログラム中でウィンドウを生成するライブラリ
コールを何度も呼び出すことでウィンドウを生成してい
る。この方式ではたくさんのウィンドウを設計するのは
困難である。この繁雑なプログラミングを助けるツール
が考えられてはいる。こうした例である分散型ウィンド
ウ設計について図１５を用いて説明する。既存のウィン
ドウ設計ツールの具体例としては、ソフトバンク社発行
の月刊ＴｈｅＷｉｎｄｏｗｓ，１９９２−１２号のｐ
ｐ．９８−１０３に特集されているようなマイクロソフ
ト社のＶｉｓｕａｌＢａｓｉｃなどがある。Ｖｉｓｕ
ａｌＢａｓｉｃはＢａｓｉｃという言語体系でウィン
ドウの振舞いを設計するツールである。また、実開平２
−３９３１８のような画面・帳票レイアウト設計におけ
る項目情報指定方法などの関連技術がある。

【０００７】ウィンドウ設計ツールは図１５のような構
成をしている。８１は画面であり、８２は部品パレッ
ト、８３はマウスである。設計者はマウスを操作するこ
とによって画面に部品パレットから部品を選択し任意の
レイアウトを構築する。部品はマウスよって様々な属性
を与えることが可能である。設計ツールにおいて設計さ
れるものはツールによって様々であるが、通常はソース
プログラムであることが多い。このソースプログラムは
ホスト計算機側にあるライブラリ７２を使う形式で生成
される。生成されたソースプログラムに内部的に必要な
ロジックをユーザが別途開発して出来上がるのが実行プ
ログラムということになる。

【０００８】従来のウィンドウ設計ツールにおいてはイ
ベントの発生した時のロジックをソースプログラム言語
で記述するので、設計ツールが生成する内部的なプログ
ラムを細部までユーザが認識する必要がある。更に、人
が足りない点、例えば条件を与えたり、条件が重なった
場合の処置を決めたり等を補う必要があった。ところ
で、この方法では、テキスト表示ウィンドウにある一定
の表示パターンを持たせる場合には、それぞれ条件が異
なるので、毎回プログラムの設計を行う必要がある。

【０００９】

【発明が解決しようとする課題】従来のマルチウィンド
ウを使ったクライアントプログラムとウィンドウサーバ
による画面設計と設計後の入力において、クライアント
とサーバ間のデータ転送量が多く、プロトコルが複雑に
なり通信量を抑えることができないという課題があっ
た。それに付随してホスト計算機側に対する割り込みの
負荷も大きくなる課題があった。また、オフィスコンピ
ュータなどに固有の、入力エリアとしてのテキスト入出
力にはある一定のパターンがあるにもかかわらず、この
ようなコールバックルーチンを毎回設計する必要があ
り、クライアントプログラムの一部を常に設計し、開発
する必要がある。つまり、ユーザプログラムの開発の負
荷が大きいという課題があった。

【００１０】この発明は上記の課題を解消するためにな
されたもので、ウィンドウ上の画面設計のためのプログ
ラム作成の負荷量を減らし、また端末とホスト間の通信
量を減らしホストへの割り込みの回数を減らしたウィン
ドウ設計装置とウィンドウ入力装置を得ることを目的と
する。

【００１１】

【課題を解決するための手段】この発明に係わるウィン
ドウ設計装置は、画面毎にウィンドウ構成部品を選択
し、その位置・大きさを指定する設計部と、こうして選
択された構成部品の位置・大きさ情報を部品情報リスト
としてファイルに管理する部品管理部と、外部からのト
リガによって画面から設計された部品情報をファイルに
入れたりファイルされていた部品情報を読み出して画面
表示するファイルＩ／Ｏ管理部とからなるウィンドウ生
成手段を備えて、このウィンドウ生成手段で生成された
画面単位でウィンドウファイルを用意するようにした。
請求項２の発明は、請求項１の発明に、部品情報中にコ
ールバック情報の部分を付加し、このファイルを参照使
用時にこのコールバック情報から次の動作が引き続きト
リガされるようにした。

【００１２】請求項３の発明のウィンドウ入力装置は、
ウィンドウをオープンまたはクローズする参照部と、入
力データの種類または範囲または長さを検査するチェッ
ク部と、入力データに必要に応じて記号を付加しまたは
編集する編集部とを付加したウィンドウサーバを備え、
ホストからのトリガにより、端末側で管理されているウ
ィンドウファイルを読み出し、サーバが入力データをチ
ェック・編集して後、ホストにデータを伝送するように
した。また請求項４の発明は、ウィンドウファイルの部
品情報中に部品属性情報部分を設け、外部から部品属性
変更のトリガがあると、対応する部品属性情報を書き換
え、書き換え後の部品属性に従って入力データをチェッ
ク・編集して後、ホストにデータを伝送するようにし
た。また請求項５の発明は、ウィンドウサーバに、ウィ
ンドウファイルの部品情報中のコールバック情報を参照
するウィンドウイベント検出部を付加し、画面入力を完
了後、コールバック情報を検出してこのコールバック情
報が指定する次画面のオープンまたはクローズに移るよ
うにした。

【００１３】

【作用】本発明のウィンドウ設計装置は、ホストからの
トリガであっても、端末で閉じたウィンドウ生成ツール
により、サーバからのイベントはウィンドウ生成ツール
に与えられ、画面を介しての問答形式で必要な画面構成
部品を所定の位置に置く画面設計がなされ、設計された
画面単位のデータとして例えば端末のデータベースにフ
ァイルされる。請求項２の発明は、更に画面設計上の領
域にコールバック情報表示領域が設けられ、このデータ
も同一ファイルに収容される。

【００１４】本発明のウィンドウ入力装置は、ホストか
らのトリガであっても、参照、チェック、編集機構を付
加したサーバにより、データベース中の対応ファイルが
読み出され、それに基づくデータ入力に対し、端末で閉
じたチェック、編集がなされた後、データがまとめてホ
ストに転送される。請求項４の発明は、更に、データベ
ース中の対応ファイルが読み出されて後、その中の属性
変更指定の構成部品の属性情報が指定値に書き換えられ
る。サーバによる入力データのチェック、編集は変更後
の属性によって行われ、その後のデータがまとめてホス
トに転送される。請求項５の発明は、更に、データベー
ス中の対応ファイルが読み出されて後、入力データのサ
ーバによるチェック、編集がなされ、その後のデータが
まとめてホストに転送されて完了後、ファイル中のコー
ルバック情報がウィンドウ検出機構で読み出されて、そ
の情報の指定のファイルに処理が移る。

【００１５】

【実施例】

実施例１．本発明は、端末側にウィンドウ生成ツールを
設け、このツールで画面設計を端末側で閉じて実施でき
るようにし、ホスト側のクライアント・プログラムでウ
ィンドウ画面を詳細に設計しなくてよいようにした。ま
た設計されたこれらの標準画面によるデータ入力を、端
末側に設けた付加機構で完全なデータとしてからホスト
に送る構成とした。図１（ａ）は本発明の一実施例のウ
ィンドウ設計・入力装置の構成図である。図において、
１はウィンドウサーバ、２はホスト側にあるクライアン
ト・プログラム、３は同じくライブラリである。４は端
末のディスプレイ、５はディスプレイ画面中の入力領域
である。また１１はウィンドウサーバに付加したデータ
ベース参照機構、１２は同じくチェック機構、１３は同
じく編集機構、１５はウィンドウ生成ツール、１６は設
計された画面が単位となるファイルを多数収容したデー
タベースである。図１（ｂ）はウィンドウサーバ１中の
付加したチェック機構１２と編集機構１３の具体的な処
理内容を示した図である。

【００１６】図２（ａ）はウィンドウ生成ツール１５の
構成部分であるウィンドウ設計部、部品管理部、ファイ
ル管理部が分担する処理の内容を示した図である。図２
（ｂ）はウィンドウ生成ツール１５を使用してユーザが
実施する画面設計のフローを示すフロー図である。図３
ないし図５は、このフロー図の代表的なステップでの画
面表示の例を示す画面表示図である。図において、２１
はメニューバーと呼ばれる主操作選択用の領域、２２は
部品を選択するツールボックス、２３は描画用ウィンド
ウである。画面中の他の説明用の番号のものについては
動作説明時に述べる。図６は、画面設計で編集機能を指
定する時の画面の例を示した画面表示図である。図にお
いて、３１はメニューバー２１で編集を選択した時に表
示される編集機能指定画面の例を示す図である。図７
は、ウィンドウ生成ツールで設計された画面の仕様をデ
ータとしてデータベースに格納したファイルの内容を説
明する図である。図中の説明用の番号のものについては
動作説明時に述べる。図８（ａ）は、コールバック動作
時の編集機構１３の動作を説明するフロー図で、図８
（ｂ）は、図２のファイル中のコールバックテーブルの
収容状態を示した図である。

【００１７】次に画面設計時の動作を説明する。図２
（ｂ）において、ウィンドウ生成ツールのウィンドウ設
計部は、ステップＳ１でユーザの起動により図３の描画
用ウィンドウ２３内には未だ何も表示がない初期画面を
表示する。次いでユーザは、ステップＳ２でツールボッ
クス２２よりマウスでクリックして、ステップＳ３で画
面設計で必要とする部品を描画用ウィンドウ２３内にも
ってくる。図３の例では、ツールボックス２２中の２５
のラベルと２４のボタンを描画用ウィンドウ２３内の２
６のラベル位置、２７のラベル位置、２８のボタン位置
にステップＳ２とステップＳ３を繰り返して持ってきて
いる。次いでステップＳ４でラベルをダブルクリックす
ると、描画用ウィンドウ２３内に２９のラベルの仕様指
定領域が表示され、ユーザはラベル２６の番号、位置
（Ｘ、Ｙ座標）、大きさ（幅、高さ）、表示文字列の種
類（数字、アルファベット、文字）その他を指定する。
他のラベル、ボタン、テキスト等も同様に表示され、同
様に指定される。これらがウィンドウ設計機構が受け持
つ機能である。

【００１８】画面設計内にテキスト入力のデータを編集
する必要がある時は、更にツールボックス２２の対応部
品であるテキストをダブルクリックして、描画用ウィン
ドウ２３内にそのテキスト対応の３１の編集用の仕様入
力画面を表示する。そして図１（ｂ）に示した各種の編
集機能を、３２のカラム数、３３の数字編集出力、３４
のコンマ指定、３５の小数点指定、３６のオートマチッ
クエンター、３７の日付編集、３８のフィールドの入出
力区分を選択して後、３９の了解をマウスでクリックす
ると編集データが保持される。逆に、保持されていた仕
様を呼び出して（部品ロード）、変更したりキャンセル
３９することもできる。

【００１９】共通画面の仕様入力時の便宜、例えば異な
るテキスト領域に順次仕様または編集データを入力した
い場合等を考えて、部品（例えばテキスト）設計画面を
順次描画用ウィンドウ２３内に表示したい時は、その部
品の仕様入力後にコールバックを指定する。この種類は
図２（ａ）のコールバックの内容にある。各部品毎に保
持されていた設定仕様は、新規セーブすると部品毎に図
７の内部情報形式でデータとしてファイルされる。これ
はテキストの情報形式の例で、４１の部品（テキスト）
番号、４２の画面（親ウィンドウ）番号、４３の部品の
種類（この場合テキスト）、４４の位置・大きさ・文字
列種類・その他の情報、４５のフォント、４６の最大カ
ラム数、４７のオートマチックエンター、４８の数値出
力タイプ、４９の表示カラム数、５０の小数点以下の桁
数、５１のコンマの有無、５２の小数点の有無、５３の
数値編集の有無、５４の日付編集の指定、５５の入出力
区分がある。このときコールバックの情報は図７の情報
形式中のオートマチックエンター４７にポインターが入
り、図２（ａ）のコールバックテーブルでアクションが
指定される。これらの部品毎の情報の保持・変更は部品
管理機構の機能である。

【００２０】ステップＳ５で画面設計に必要な全部品が
レイアウトされ仕様が定まると、ステップＳ６でメニュ
ーバー２１でファイルをダブルクリックしてセーブを指
定し、図５のセーブ画面が現れる。これはファイル管理
機構が受け持つ機能である。他の新しい画面設計をする
時は、ステップＳ９でイニシャライズすると、図３の描
画用ウィンドウ２３内が無表示の初期画面に移る。

【００２１】実施例２．既に端末のデータベースにファ
イルされている基本設計画面を利用して、入力データを
ホストに送る、実行時の構成と動作を説明する。本発明
の他の目的である端末ホスト間の通信量が削減されるこ
とを示す。図１（ａ）は先に説明したように、発明の実
施例のウィンドウ設計・入力装置の構成図である。図の
ウィンドウサーバ１に付加したデータベース参照機構、
１２のチェック機構、１３の編集機構が入力、またはプ
ログラム変更のための構成要素である。

【００２２】図９はウィンドウサーバ１の動作フローチ
ャート図であり、ステップ番号の詳細は動作の説明時に
説明するが、二重枠で囲んだステップＳ３１ないしＳ３
６は上記の新しい付加した機構部分の動作であり、その
他の一重の枠のステップＳ２１ないしＳ２４は従来のウ
ィンドウサーバの動作である。図１０は実際の画面と対
比したウィンドウサーバの動作フロー図である。また図
１１は、図１０の入力データをホストに送信するまでの
詳細動作ステップを示す動作フロー図である。図におい
て、一点鎖線で囲まれた部分がホストで担当する処理で
あり、その他の部分は端末のサーバが担当する。

【００２３】次に基本設計画面を用いたデータ入力時の
動作を説明する。まずホスト側からは、ある指定のフォ
ーマットに従って入力データを送らせたい、とする。ち
なみに従来の方法では、入力画面の部品の位置、大きさ
を端末に送り、また検出されたデータも入力毎にホスト
に送られていた。本発明によれば、指定フォーマットに
対応する基本設計画面番号のファイルでデータ送信を指
定するだけでよい。図９のステップ２１で端末とホスト
を結ぶネットワークが接続され、ステップＳ３１でマク
ロ命令であることを知り、ステップＳ３２でファイルを
オープンする。これは同時に図１０のステップＳ４１に
相当する。画面を表示装置に表示し、続いてステップＳ
４２で出力フィールドに、例えば「数字を入力してくだ
さい」と表示する。ステップＳ２３でウィンドウサーバ
が入力データのイベントを検出しても、例えば３桁の数
字入力が終わるまでは、ステップＳ３４，Ｓ３５，Ｓ３
６のループで完了を待つ。ステップＳ３６で入力フィー
ルドの３桁の数字入力を検出すると、図１０のステップ
Ｓ４３になり、ステップＳ２４のホストへの送信の段階
となる。つまり、図１０のステップＳ４１からＳ４３ま
では、従来と異なって、すべて端末側の処理となる。ホ
ストではステップＳ４４に至って初めてホストで必要と
する処理を行う。端末とホスト間の通信は、ファイルの
オープンと、データの連続転送だけである。

【００２４】図１１は、図１０のステップＳ４２とステ
ップＳ４３の間の、入力フィールドに端末でオペレータ
がデータを入れていく状態を示す動作ステップである。
図１０の例で、基本設計画面で入力フィールドに数字チ
ェック情報が指定されているとすると、ステップＳ５１
で入力コードがチェックされる。エラーであれば端末は
ホストに通知して終了する。ホストではこれを受けて、
従来例と同様、エリアをクリアし、エラーメッセージを
出力して終わる。入力コードが数字であれば、ステップ
Ｓ５２，Ｓ５３，Ｓ５４で順次バッファに保存し、ポイ
ンタを進めて、３桁の数字入力を検出して、ステップＳ
５４で、つまりステップＳ４３でホストに通信する。ホ
ストではこのバイナリ・コード列を変換し、ホストで必
要な処理をする。従来例では、図１１のステップＳ５１
からＳ５４までが、すべてホストからの指示によるた
め、通信路上のやりとりが多かったのに比べ、交信が少
なくなることがわかる。

【００２５】実施例３．本実施例では、基本設計画面を
利用した部分変更画面をホストのプログラムで組み、端
末のデータベースを大きくしないで各種の設計画面によ
る入力を可能にする。また、ある種のシステムでは、入
力画面が標準化されていて、この標準画面で、多様な入
力をしたいという要求もある。図１２（ａ）はウィンド
ウ画面を構成する部品の属性を説明する動作フロー図
で、図１２（ｂ）はその属性テーブルの例を示す図であ
る。

【００２６】次に動作を説明する。基本設計画面を使う
入力では、ホストからのファイル指定により対応画面が
読み出され、図９のステップＳ３２で、その画面内に含
まれる各部品（ラベル、テキスト等）は所定の位置に所
定の大きさで描かれると共に、例えばテキストならデー
タベース中に設けられた別の６１の部品属性テーブルが
ステップＳ６２で読み出される。基本設計画面では、こ
の入力領域の意味が登録されていて、例えば西暦の日付
であったとすると、部品属性テーブル６１の６４のチェ
ックルーチンがステップＳ６３で確認され、ステップＳ
６４で読み出される。必要なら、更に６５の編集ルーチ
ンも読み出されて、数字８桁の入力に対して年・月・日
が付加される。この完全な入力データがステップＳ６５
すなわちステップＳ２４でホストに送られる。

【００２７】ところで、基本設計画面と同一画面で、し
かし入力領域の意味が認識番号の９桁であったとする。
データベースが大きくて多数の画面を用意できればこう
した必要性は少ないが、同一の基本設計画面を、異なっ
た意味を持つ画面に流用することも多い。この場合はホ
ストから基本設計画面のファイル指定の後に、認識番号
入力への属性変更の通知が続く。このときはステップＳ
３３で属性変更が検出され、ステップＳ７１でこの領域
がテキストであることが確認され、ステップＳ７２でこ
の指定の属性が認識番号であるので、ステップＳ７３で
部品属性テーブル６１の６３の認識番号対応ＩＤをみ
て、ステップＳ７５で収容されている６４の認識番号用
チェックルーチン（例えば数字９桁）で元の西暦日付チ
ェックルーチンを書き換える。以後、オペレータによる
端末への入力を認識番号チェックに基づいて行い、９桁
の入力が完了すると、ステップＳ２４でホストに通信を
行う。

【００２８】実施例４．本実施例では、以下のような要
求に対処することを目的とした例を述べる。すなわち、
設計画面中の各部品を途切れなく順次ラベル、チェッ
ク、編集画面表示して、仕様を記述していきたい場合が
ある。また他の要求として、複数画面の入力を１つの単
位として連続入力し、まとめて一連のデータとしてホス
トが処理したい場合もある。図１３は、コールバックが
組み込まれた情報に対し、端末側のウィンドウサーバ示
す動作フローを表した図である。

【００２９】コールバック動作の説明をする。この場合
はウィンドウ生成ツール１５を使った画面設計時に、図
８（ａ）のフローにより図２及び図８（ｂ）のコールバ
ックテーブルが既に用意されている。画面表示または入
力の実行時には、図１３の動作フローにより、端末のサ
ーバはステップＳ８２で端末全体を動かすオペレイティ
ングシステムからコールバック要求を検出し、ステップ
Ｓ８３でコールバックテーブルを見に行く。ステップＳ
８２とＳ８３は、詳しくはステップＳ８５からステップ
Ｓ８９となっており、例えば属性が２と指定されている
と、指定の画面を表示すると共に、元の画面を消去す
る。またスクロール対応の属性が指定されていれば、入
力データを全てサーバに送り、画面をクリアする。これ
らのコールバックアクションの内容は、図８（ａ）のス
テップＳ１１で画面のウィンドウに表示ができ、アクシ
ョンを指定できる。こうして画面の起動、データの転
送、消去を連続して行え、従来のように全てのイベント
をホストから指定しなくてよいのは勿論、端末で画面を
構成する各部品毎のデータ作成を一括して行う方式と比
べても、各部品毎の起動、終了指定を省略でき、プログ
ラム作成の負荷を減らし、通信量を削減できる。

【００３０】

【発明の効果】以上のようにこの発明によれば、ウィン
ドウ生成手段とファイルを収容するデータベースを設け
たので、必要があれば画面との対話形式でデータを選択
し、データ形式で保存管理、インデックス指定による再
使用ができる効果がある。またサーバに参照、チェッ
ク、編集機構を付加したので、クライアントからの簡単
な指令で、サーバにおいて一連のチェック編集後のデー
タをまとめて転送しクライアントプログラム作成の負荷
を減らし、かつクライアントとサーバ間の通信量を削減
する効果がある。請求項４の発明では、少ない標準画面
で、より多くの異なる意味を持つ領域の画面を用意で
き、データベースの量を減らす効果も得られる。更に、
ファイルにコールバック情報を備え、サーバでこれを検
出するウィンドウイベント検出手段を付加したので、ホ
ストプログラムからの指定なしに連続動作をし、プログ
ラム作成の負荷と、通信量を減らす効果がある。

【図面の簡単な説明】

【図１】本発明の一実施例のウィンドウ設計・入力装置
の構成図と付加チェック機構、編集機構の処理内容を示
した図である。

【図２】図１のウィンドウ生成ツールのウィンドウ設計
部、部品管理部、ファイル管理部の処理内容と、画面設
計を示す図である。

【図３】図２のフロー図中のステップＳ２，Ｓ３の画面
表示の例を示す図である。

【図４】図２のフロー図中のステップＳ４の画面表示の
例を示す図である。

【図５】図２のフロー図中のステップＳ６の画面表示の
例を示す図である。

【図６】図１の構成で編集機能を指定する時の画面表示
の例を示す図である。

【図７】設計画面を収容するファイルのデータ内容を示
す図である。

【図８】コールバック動作時のフロー図とコールバック
テーブルの内容説明図である。

【図９】本発明の一実施例のウィンドウサーバの動作フ
ロチャート図である。

【図１０】図９のウィンドウサーバの、マクロな画面と
対応させた動作フロー図である。

【図１１】図１０のデータ入力の送信までの詳細動作フ
ロー図である。

【図１２】部品属性を説明する動作フロー図と属性テー
ブルの例を示す図である。

【図１３】コールバック動作の動作フロー図である。

【図１４】従来のウィンドウシステムの構成図である。

【図１５】従来のウィンドウ設計ツールの仕様方法を説
明する図である。

【符号の説明】

１ウィンドウサーバ１１データベース参照機構１２チェック機構１３編集機構１５ウィンドウ生成ツール１６データベース２１メニューバー２２ツールボックス２３描画用ウィンドウ３１編集用ウィンドウ６１部品属性テーブル

Claims

【特許請求の範囲】

【請求項１】画面毎にウィンドウ構成部品を選択し、
位置・大きさを指定する設計部と、上記選択された構成
部品の位置・大きさ情報を部品情報リストとしてファイ
ルに管理する部品管理部と、外部からのトリガによって
画面から設計された部品情報をファイルに入れ、または
ファイルされていた部品情報を読み出して画面表示する
ファイルＩ／Ｏ管理部とからなるウィンドウ生成手段を
備え、上記ウィンドウ生成手段で生成された画面単位でウィン
ドウファイルを用意するウィンドウ設計装置。
【請求項２】部品情報中にコールバック情報の部分を
付加したことを特徴とする請求項１記載のウィンドウ設
計装置。
【請求項３】ウィンドウをオープンまたはクローズす
る参照部と、入力データの種類または範囲または長さを
検査するチェック部と、入力データに必要に応じて記号
を付加しまたは編集する編集部とを付加したウィンドウ
サーバを備え、ホストからのトリガにより、端末側で管
理されているウィンドウファイルを読み出し、入力デー
タをチェック・編集して、ホストにデータを伝送するウ
ィンドウ入力装置。
【請求項４】ウィンドウファイルの部品情報中に部品
属性情報部分を設け、外部から部品属性変更のトリガが
あると、対応する部品属性情報を書き換え、書き換え後
の部品属性に従って入力データをチェック・編集するこ
とを特徴とする請求項３記載のウィンドウ入力装置。
【請求項５】ウィンドウサーバに、ウィンドウファイ
ルの部品情報中のコールバック情報を参照するウィンド
ウイベント検出部を付加し、画面入力を完了後、コール
バック情報を検出して上記情報が指定する次画面のオー
プンまたはクローズに移ることを特徴とする請求項３ま
たは請求項４記載のウィンドウ入力装置。