入力データの判定について

過去の桐井戸端ＢＢＳ　（桐ver.８）

4917	入力データの判定について	tuji	2000/02/29-23:42
Ｖ８ＳＰ３です。ＤＯＳ桐のを使っていた頃、キー入力で変数に値を格納し、画面表示で画面にデータを表示させ、行追加するという非常に安直な一括処理を組んでいたのですが、同じ様なことをＷｉｎ桐で出来ないかと思い色々いじり、フォーム呼出しコマンドを使い、テキストオブジェクトのソースに変数を記述してあるフォームを呼び出し、データを入力（変数に格納）し、行追加する処理は出来たのですが、ＤＯＳ桐の頃はキー入力で変数に格納された値を条件コマンドで判定させ、あり得ないデータが入力された場合には再度キー入力に処理を戻し、正しい入力をさせるようにしていたのですが、今回試しで作ったものでは、全て入力した後、コマンドボタンで一括に戻してから判定するような処理にしかならず、２カ所以上間違えた場合に非常に面倒なことになるため、変数に格納するごとにデータの判定をおこないたいと思っています。どなたか良いアイディアはございませんでしょうか？個人的にはイベント無しでなんとかならないものかと思っています。
4920	Re:入力データの判定について	宮城	2000/02/29-23:54
記事番号4917へのコメント tujiさん、こんばんは。もう少し説明して下さい。 >個人的にはイベント無しでなんとかならないものかと思っています。とお書きになっているということは、「古典的」一括処理かなとも思うのですが、そうなるとDos桐の一括処理でできていたことが、なぜWin桐でできなくなるかがわからないのですが。行訂正で１件ごとに判定してはできないのですか？
4925	入力データの判定は、制約条件で行うのが正解です	佐田　守弘	2000/03/02-00:01
記事番号4917へのコメント tujiさん結論を先に言いますと、入力された値のチェックは、項目制約で行うのが正解です。項目制約での値のチェックであれば、表定義だけで行う事ができ、フォーム編集などにも引き継がれます。なお、項目制約で入力チェックを行う場合には、表の項目値をソースとしたフォームを使う必要があります。キー入力値を変数で受けてからチェックして、表に行追加したいとの事ですが、この理由がマスタファイルに対して、直接の編集をさせたくないのでしたら、マスタファイルと同じ定義内容のワークファイルを作成して、ワークファイル上に入力を行ってみて下さい。ワークファイルの入力値は、後でマスタファイルの方に読込む形で回収します。変数をソースとしたフォームは、私も桐ver.7時代に名刺管理システムで使ってみました。不可能な方法ではないのですが、やはりフォームのソースは表の項目値にした方が何かと便利です。ですから、上記の方法でマスタファイルかワークファイルに入力し、制約条件でチェックするのが最も賢い方法かと思います。余談ながら、制約条件が完備していなかった桐ver.3時代には、変数で受けて値をチェックしてから表に書き込む必要があり、一括処理がかなり複雑になりました。また、個人的には使いたくないとの事ですが、値チェックを行うもう１つの方法は、入力後イベントを使って、項目値の入力が終わったら、その値をチェックする方法です。入力後イベントでは、手続き定義開始　<オブジェクト>::入力後( 参照文字列 &編集文字列，長整数 &モード，参照長整数 &入力継続) の様に書きます。イベントが発生すると、入力を行った文字列は&編集文字列に代入されていますから、この値をチェックします。そして必要ならイベントハンドラの中で&編集文字列の値を訂正して戻す事も可能ですし、&入力継続に1を代入すれば、変数のやり直しが行えます。イベントを使いたくない理由は、分かりにくい、難しいという事だと思いますが、使ってみれば一括処理よりも易しいはずです。佐田守弘(KS-00119) 近日中に一括処理とイベントの違いを比較したコンテンツを掲載する予定です。
4930	Re:入力データの判定について	bonito	2000/03/02-12:22
記事番号4917へのコメント tujiさん、こんにちは。気にはなっていたんですが、書き込むヒマがなくて、ちと遅いコメントですが・・・。佐田先生の回答を見て、ハードルの高さに落胆されているかも知れないと思い、もっとも安直な方法を披露します。 >全て入力した後、コマンドボタンで一括に戻してとありますから、このボタン（仮に追加実行）の「機能名」1を「その他」の中の「実行条件」とし、「パラメータ」1に「&Ａ<12 .and &Ｂ<31」とか式を入力、「機能名」2に「一括処理に戻る」とすればどうでしょう？ついでに入力ガイド兼エラー表示用のテキストオブジェクトを用意して、 #条件選択(&Ａ="","Ａにxxを入力",&Ａ>13,"大きいよ",…) とか・・・、編集属性式で色も変えたりとか・・・。でも欠点あり、こういう場合、いくつもの入力値のうち、正しくない入力値のオブジェクトにフォーカスを移動したいところですが、自動的にはもちろん、ダメダメ(^^; 佐田先生の言われる通り、入力用の別表を作って、項目制約あるいは行制約を設定する方がよりベターな方法でしょうかネ。まぁ、ホントはイベントが一番簡単なんですが、この為だけにＫＥＶファイルを作るのもネ。
4935	Re:入力データの判定について	tuji	2000/03/02-16:31
記事番号4917へのコメントコメントを付けていただいてありがとうございます。投稿後、自分なりに考えてみたのですが変数をソースとしたフォームを使っているのは、Ｖｅｒ７が出た頃にＤＯＳ桐で作った項目を入れた帳票を使う一括処理を動かしてみたところ、（特にＷｉｎ用に書き換え等を全くおこなわずに。）伝票番号を出す処理でで、代入　&番号=0 位置指定　行番号=先頭代入　&番号=[番号] 繰り返し　(.NOT #EOF) 　位置指定　行番号=次行　条件　(&番号<[番号])　代入　&番号=[番号] 繰り返し終了なんて処理をおこなっており、通常は帳票を表示する前にこの処理をおこなうようにしてあり問題なかったのですが、あるタイミングになると、分岐処理の不具合で帳票を表示したままこの処理を実行するようになっており、順番にレコード表示が変わるのが目に見えてわかるほど遅かったため、フォームのソースに表の項目値を設定しているから処理的に遅くなってしまうのかと思い、項目数分の変数を用意しデータを入力し、表に行追加した方が処理的に早いのではないかと、いうような印象が残っていたため、このような方法をとりました。この現象に関しては、改めてＤＯＳ桐で同じタイミングを再現してみましたが、処理時間が少しかかっているなとは思う程度で、順番にレコード表示が変わるのが見えるということもなかったので、当時は変えようと言う気にもならなかったのかなと想像してます。あと、変数を使うことによって例えばｈ１２０３０２という入力をさせ、入力後に計算式でｈ１２／３／２と変換し、表に追加できれば入力の省略になるということもあります。同じようなことを表を直接編集しておこなうと項目が一つ余分にいるんですよね？（文字列で保存すればいいのかもしれませんが折角日時型があるので。）というわけで表を直接編集せず、変数を使いっておこないたい。ただ、そうすると項目制約式を設定しても、行追加する時点（フォームでの入力を終え一括に戻った時点）でしか判定できない。テキストオブジェクトに入力するたびに一括に戻れれば判定できるのに等と思うと、なんだそれって要はイベント？ということになり、今自分が作っている部分を残して（勿体ないので）自分の思うような処理をおこなうには、イベントしかなさそうだなという結論になりました。ちなみになぜ一括処理でといいますと、イベント、或いは表に対し色々な設定によって、全体がわかりにくくなりそうだという漠然とした印象がありました。表は単なる入れ物、フォームは入力用の道具、細かい動きは一括でやる、一括を見れば全体が見渡せるぞといった感じで、ＤＯＳ桐の頃からやってましたもので・・・。要は悪あがきの一つでも出来ないかなと思いまして。これからは少し頭を切り換えていこうかなと思っております。
4942	Re:入力データの判定について	宮城	2000/03/02-19:22
記事番号4935へのコメント私でしたら次のように処理します。名札　Ａ項目入力行訂正　フォーム，[Ａ]，終了キー＝＆終了キー，終了状態＝＆終了状態　ケース開始　　ケース（＆終了キー＝２７）　　　確認　"入力中止………[ENT]" 　　　行削除　　　分岐　適当な戻し先名札名　　ケース（「ＯＫとする条件式」）　　ケース　その他　　　確認　"入力異常………[ENT]"　　　　　　　分岐　Ａ項目入力　ケース終了　　名札　Ｂ項目入力行訂正　フォーム，[Ｂ]，終了キー＝＆終了キー，終了状態＝＆終了状態　ケース開始　ケース（＆終了キー＝２９）　　　分岐　Ａ項目入力　　ケース（＆終了キー＝２７）　　　確認　"入力中止………[ENT]" 　　　行削除　　　分岐　適当な戻し先名札名　　ケース（「ＯＫとする条件式」）　　ケース　その他　　　確認　"入力異常………[ENT]"　　　　　　　分岐　Ｂ項目入力　ケース終了

戻る