一括処理かイベントかどちらを使うべきでしょうか

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

4810	一括処理かイベントかどちらを使うべきでしょうか	磯田	2000/02/22-01:40
久しぶりに書き込みをさせていただきます。さて、現在桐５で構築してきた成績管理のプログラムを V8に移行させようと思いながらも、なかなか勇気が出ずにいます。というのも、プログラムを書き始めるのに、フォームから入ってイベント処理を中心に進めるべきなのか、イベントは殆ど無視して一括処理中心でいくのか判断がつきません。両方で作ってみると言うほどの時間的余裕もないのでどなたかよいアドヴァイスよろしくお願いいたします。
4812	一括処理かイベントか	Ogo	2000/02/22-02:47
記事番号4810へのコメントついこの間から幾つか触ってみましたが、「内容による」としか言いようがありません。桐８の「イベント処理」はかなり中途半端です。でも、フォームにボタンを配置して、後はそのボタンを押した時にあ～してこ～してという簡単なものを作るには圧倒的な時間短縮効果があります。しかし、これまでの一括処理で行なって来たことが複雑であればあるほど、どのみち（上記のように、ボタンに機能を割り付けるにしても）一括処理を書く必要が出ます。フォームに配置する各ボタンには１つにつき４ステップのみで、しかも極端に制限されたことしか実現できません。結局は .KEV という名前の一括処理サブルーチンを延々と書く破目に陥るのです。更に、 .KEV に書けるコマンドにはべらぼうに制限が多く、何かと不自由な思いをします。ついでにもう１つ重要なのは、一括処理 *.CMD はサブルーチン化が容易で、特に「ライブラリ」という仕組みまで用意されているので、一旦自分で組み上げたものは後々の血となり肉となりやすいということです。私がこの間組んだ中で、フリー公開している「パスワード認証」や「バックアップ処理」は、そろそろ「一括処理 ( CMD ) を導入部にした方がベターだった」と後悔し始めている（ (^^; オオゲサ）ところです。でも、たとえ一括処理 ( CMD ) をメインにするにしても、体裁やユーザーインターフェースの充実度等を考えると、結局フォーム上でのイベント処理を取り入れて .KEV を併用する状況にならざるを得ないと思います。（だって、一括処理でメニューを作ろうとすれば、それだけでもうメゲルのですよ）桐５で一括処理に自信があるのなら、とりあえず今はフォームと KEV だけでどこまでできるのかを見極めるのが最善かと。限界が判る頃には、使い分けの見当も多分つくと思いますよ。
4822	ありがとうございます	磯田	2000/02/22-14:53
記事番号4812へのコメント Ogoさん、早速のresありがとうございます。おっしゃるとおり、イベントはとても便利そうに見えるのですが、ちょっと複雑な処理になった時にどこまで対応できるのがということが、もっとも不安に感じるところです。今後管理工学さんがこの一括処理とイベントのバランスをどの様にとっていくのか、見守りたいと思います。そして、できればユーザーに分かりやすいように、この２つの関係を明確にしてほしいと思います。とりあえず、一括処理中心でプログラムを組んで、それに少しずつイベントを取り入れていく、といったところが現実的なところでは無いかと思います。また、よろしくお願い致します。
4826	イベントと一括処理は似ていて非。別物と考えましょう	佐田　守弘	2000/02/23-01:19
記事番号4810へのコメント磯田さん実はこの課題について、ここ数日いろいろと考えて来ていたところです。そして現在の思うところで言えば、「イベントと一括処理は似ていて非なるもの。使う目的が異なるのでは」と思うに至りました。 ●その前に脱線この課題について、しばらく前に管理工研の開発に、「管理工研としては、どちらを主体で使う事を前提としているのか」について尋ねてみました。その答えは、「桐ver.8では、イベント主体で使う事を想定している」との事でした。この前提に立って、私のHPにも関連コンテンツを掲載して来たのですが、ここに来て、それは必ずしも正しくないのでは、と思う様になって来ています。管理工研が考えている「イベント主体で使って欲しい」は、１つの前提を置けば正解なのだと思います。その前提とは、桐のユーザーの９割は会話処理で使うユーザーであるという前提です。 ●イベントは会話処理の補助手段会話処理主体で使う一般ユーザーが、会話処理から一歩踏み出すものが履歴であり、更にそこから数歩踏み出した所にあるのがイベントなのではないでしょうか。とは言え、桐ver.5ユーザーにとって、イベントなるものは余りに唐突な概念である事も確かです。ですから、一括処理以上に難しく見えてしまいます。これは、Windows版の桐に移行した会話処理主体のユーザーにとっても同じです。ですが、実際に行ってみると、「イベント処理は会話処理ユーザー向けにできているな」と感じます。 ●一括処理はシステム構築の手段桐が本格的なシステム構築にふさわしいかどうかと言った議論があるかとは思いますが、そこそこのシステムをユーザー自身の手によって、手軽に作れる事も事実です。ある程度の規模があり、手順がきちんと決まっている処理を行わせるのであれば、一括処理の方が適しているのではないかと考えます。 ●イベントと一括処理とは機能が異なるイベントは会話処理の延長線上にあり、一括処理は予め想定されたプログラムである、といった性格から考えれば、その機能の違いはおのずと分かると思います。分かりやすい例でいえば、イベントの「行追加」は、会話処理の行追加のメニューを選んだのと同じで、行が追加され、編集状態になります。ここでESCキーを押せば、行追加が取り消されます。まさに会話処理です。これに対して、一括処理の行追加は実際に１行追加されます。一括処理には「編集状態」という状態が存在しません。ない訳ではないのですが、これは会話処理モードの機能です。イベントと一括で利用できるコマンドや実行できる機能に違いがあるのは、このモードの違いだと思います。 ●どちらを使うべきか私もOgoさんと同意見で、使う目的に応じて使い分けるべきではないかと思います。自分で作って自分で使うものであれば、イベントの方が便利なのではないでしょうか。一方、人が使うために作るのであれば、一括処理の方が適している様に思います。ただし、イベントでなければできない様な機能も存在しますし、その様な事を一括処理の中で行いたい場合があります。この場合には、一括処理主体でイベントを併用するのが良いのではないかと思います。つまり、大きなプログラムの流れは一括処理で作成し、部分的な細かい点はイベントで補助するといった事になるのかと考えます。佐田守弘(KS-00119)
4829	一括処理がいいと思う	tomo	2000/02/23-06:32
記事番号4810へのコメント私も高校で成績処理をしています桐５まで一括処理だったのでWIN桐でも同じですイベントには興味がありますが業務上どうしても必要と言う場面には出会ってません (私が寄せられる要望を無視しているだけ？) 成績処理の担当者は何人居ますか？また、転勤の頻度は？私の所は５人です主として２人、他は勉強しながら聞きながらですまず表の項目定義からきちんと相談して組まないと大変ですまして他人の作ったフォーム＆イベントなど簡単には解読できません一括処理でも解読は疲れる作業ですが上記よりはましですたった一人でこの先の教育課程の変更などにも対応していくならイベントでも大丈夫でしょうが複数人でする仕事ならイベントは避けた方がいいと思います少なくとも大切な処理には
この記事は佐田守弘氏のＨＰによって詳しく説明されています。

戻る