過去の桐井戸端ＢＢＳ　（桐談義・その他）
1366 イベントドリブンの予想？ 悲しげ 1999/2/18-01:12
（「早く完成したい」さん、もうひとつの方も読んでね）(^^;)
さて、別稿でもふれましたが、次のような処理があるとします。

◆ダイレクトメール宛名のタックシール印刷。
◆年齢層別と性別の多重絞り込みを行った上で、地区別の並びで印刷。
◆２重発送とならないように、発送済みのものには処理日付を入力しておく。
◆これを「フォームからボタンで」実行したい。

私は、フォーム上での(一括処理を使わない)ボタン処理は殆ど使っていないのでナンですが、
これはかなり難しいように思いました。
一括処理を組めば、ボタンを使っても使わなくてもできるのですが、ここで私は次のようなことを
考えてみました。
たまたま、うらさんのホームページで、７月頃に「桐v8イベントハンドラーはこう使え」的な本が
出る話を読んだばかりだったので、そう思ったのですが……、
上記処理を来るべきv8の「お弁当丼」ならぬ「イベントドリブン」として料理するには、
どのようにやったらいいのか？　本件をそのモデルとして、ちょっと先走って考えてみたいと
思った次第であります。(^^;)

フォームの構成としては、
◆[性別]の指定は、「トグルボタン」の「オプションボタン」とかで「グループボックス」とする。
◆[年齢層]は、「リストボックス」辺りを使う。
　複数選択可能とするなら、それぞれ独立した「トグルボタン」の「チェックボックス」辺りを使って、
　かつ「グループボックス」化しない。
◆前回更新日の判断は、適当に計算させた１ケ月前等の値を変数に代入しておいて、「テキスト」の
　変数値として初期表示させておく。
（補足；前回更新日がこの日付以前のデータを今回印刷分として絞り込むため）
◆そして、印刷実行と日付更新のボタンを設ける。

さて問題は、これらをどうイベントとして実行させるべく組み立てるか？（ここで云うイベントとは、
せいぜいマウス左クリック程度しか想定していませんが）

一番判らないのは、実行順序や結果判断の問題です。
この場合、性別・年齢層・前回更新日関連の絞り込み順には問題ありません。
しかし、この３つが全て整っていなければ、印刷ボタンを押されては困りますね。
この辺りの判断をどうするか？
場合によっては、キャンセルボタンを用意しておいた方がいいかもしれない。
終了ボタンも、完全実行済みと中途終了（キャンセルと同義？）、検索失敗時、
などで事後処理を分岐させるべきなのか？
直前処理のデータ（完済分もキャンセル分も）を残しておくか消しておくべきか。
となると、今回新規の絞り込み条件設定とキャンセルとを、トグル／グループボックスにして
おいた方がいいのだろうか？

などなど……、幾つか考えているうちに、頭がこんがらがってきました。(^^;)
そもそもこういう発想自体がイベントドリブン的ではないのかしら？
皆様のお智慧とご意見を拝借してみたいと思って、投稿させていただいた次第であります。
1379 Re: 宮城 1999/2/19-01:25
事番号1366へのコメント
悲しげさん、こんばんは。私もこんがらがってる最中です。古い奴ほど新しいものが気になるもので
ございます。どこに新しいものが（きっちり説明してあるところが）ございましょう？
　（おお、アルコールの影響で指がすべること！）

キャンセルボタンはどんなケースでも入れておくべきです。
桐でもAccessでも、完成時には不要でも開発時プロチョンやったとき（つい次レコードへ移動を
書き忘れた、とか）壊れるの覚悟でリセットするか安全に隠しコマンドで終了するか、
精神の健康をどう保つかの問題ですね。

たぶん、ケースを使えば簡単なのでそこだけ一括処理書くのかなあ？

フォームメインで補完的に一括処理を使う・・・。
そんな使い方が出てくるのかもしれません。
1389 Re: はまだ 1999/2/20-08:02
記事番号1366へのコメント

>上記処理を来るべきv8の「お弁当丼」ならぬ「イベントドリブン」として料理
>するには、どのようにやったらいいのか？　本件をそのモデルとして、ちょっと
>先走って考えてみたいと思った次第であります。(^^;)
>
>フォームの構成としては、
>◆[性別]の指定は、「トグルボタン」の「オプションボタン」とかで「グルー
>プボックス」とする。
>◆[年齢層]は、「リストボックス」辺りを使う。
>　複数選択可能とするなら、それぞれ独立した「トグルボタン」の「チェック
>ボックス」辺りを使って、かつ「グループボックス」化しない。
>◆前回更新日の判断は、適当に計算させた１ケ月前等の値を変数に代入してお
>いて、「テキスト」の変数値として初期表示させておく。
>（補足；前回更新日がこの日付以前のデータを今回印刷分として絞り込むため
>）
>◆そして、印刷実行と日付更新のボタンを設ける。

イベントドリブン勉強中のはまだです。アクセスやビシュアルディーベースをもとに桐のイベント
ハンドラも私なりに想像してみたいと思います。
>
>さて問題は、これらをどうイベントとして実行させるべく組み立てるか？（こ
>こで云うイベントとは、せいぜいマウス左クリック程度しか想定していませんが

フォームや◆のトグルボタンやコマンドボタンはオブジェクトととなります。
イベントは実行させるものではなく、これらのオブジェクトに対してユーザがなんらかの動作をする
ことです。
フォームであれば「開く」，「閉じる」などですが、このイベントが発生したときに、開発者は
どのようなイベントプロシージャを書くかです。
Ｋ３はたぶんこのプロシージャ部分も一括処理と呼ぶとおもいますが、一括処理からフォームにいき、
またもどるというのではなく、フォームも含めた各オブジェクトのそれぞれのイベントに一括処理を
書くイコール、オブジェクトがイベントとそれぞれの一括処理をもつという考え方をすれば見通しが
良くなってくるのではないでしょうか。

>一番判らないのは、実行順序や結果判断の問題です。

当然そのなかには条件分岐文や、ケース文を書くこととなると思います。
より木目細かく自由な設定ができ、一括処理のプログラム文もよりわかり安くなってくると思います。

>この場合、性別・年齢層・前回更新日関連の絞り込み順には問題ありません。
>しかし、この３つが全て整っていなければ、印刷ボタンを押されては困ります
>ね。
>この辺りの判断をどうするか？

性別・年齢層のオブジェクトの「フォーカス取得」イベントで入力チェックし前オブジェクトの入力が
なければフォーカスを戻して実行順序を強制してもよし、印刷ボタンの「クリック時」イベントで
始めて入力チェックし実行順を強制せずともよしだと思います。

以上、私なりの考え方をお話させていただきました。
皆さんのお考えもいろいろとお聞きしたいと思っています。
いずれにせよイベントハンドラはデータベース開発言語にとって必須のものになってくると思います。
1391 Re: 悲しげ 1999/2/20-14:22
記事番号1389へのコメント
どもっ、はまださん、
実は私の関心は、現行v7.*のボタン操作上での可否ではなかったので、このようなコメントを
いただき、感謝申し上げます。

>Ｋ３はたぶんこのプロシージャ部分も一括処理と呼ぶとおも
>いますが、一括処理からフォームにいき、またもどるという
>のではなく、フォームも含めた各オブジェクトのそれぞれの
>イベントに一括処理を書くイコール、オブジェクトがイベン
>トとそれぞれの一括処理をもつという考え方をすれば見通し
>が良くなってくるのではないでしょうか。

なるほど、（フォームを含めた）オブジェクト自体がそれぞれの（イベント毎の）一括処理を持つと
云うことですね。
云い換えれば、従来の一括処理は全体的な制御にとどめ、例えばフォームに処理に移した際には、
そのフォームのイベント／一括処理として実行されると云う。
ところで、この一括処理は、イベント毎に独立したcmdファイルかなと思っていましたが、
そしてそうすっとcmdファイルだらけになってしまうので、多分オブジェクト毎に１本のcmdと
なるんでしょうね。
「手続き定義」コマンドの主な用途もこれで推測がついたような気がします。(^^)v

>性別・年齢層のオブジェクトの「フォーカス取得」イベント
>で入力チェックし前オブジェクトの入力がなければフォーカ
>スを戻して実行順序を強制してもよし、印刷ボタンの「クリ
>ック時」イベントで始めて入力チェックし実行順を強制せず
>ともよしだと思います。

なるほど２(^^;)
イベントドリブンと云うと、私はマウス左クリックくらいしか頭になかったのですが、
フォーカスの取得状態の判断なんてのもある訳ですね。
と、ここでAccess本を開いてみましたら、イベントプロパティってのが色々たくさんありますね。
ところで２、ずっこけるようなことをお訊きしますが、例えばこの「フォーカス取得」ってのは、
どのように判断するのでしょう？
ちょっと具体例みたいなものを挙げていただけるとうれしいのですが。(^^;)
1400 Re: はまだ 1999/2/21-05:52
記事番号1391へのコメント
一時、アクセスか桐か論議がはやりましたが、どちらがよい悪いのやりとりより、
所詮同じスタンドアロン型（ファイル共有型）中小企業、もしくは特定の部署で素人がなんとか
使えるソフトです。
実はそれが我々にとって最重要なのであるが）めくじらたてず、お互いのいいところを学びましょう。
そこでイベントドイブンで桐よりはるかに先をいっている。
アクセスやＶｄBASEと対比させながら、桐８の予想を私なりにやってみます。

>ところで、この一括処理は、イベント毎に独立したcmdファイル
>かなと思っていましたが、そしてそうすっとcmdファイルだらけ
>になってしまうので、多分オブジェクト毎に１本のcmdとなるん
>でしょうね。

オブジェクト毎というよりはフォーム毎（フォームオブジェクト単位）になるでしょう。
又、独立したファイルというよりは、フォームファイルに包括した形のほうが管理しやすいでしょうね。
ＶｄＢＡＳＥはこの形です。
アクセスもこのようにフォームにイベントの手続きがすべて包括されていますが、ファイルとしては
表やレポートも含むデータベースそのものが一つのファイルになっています。
従来のcmdファイルはどうなるか．．フォーム間で共通処理をイベントの手続きに重複して書くのでは
なく、一つのcmdファイルにまとめ、イベントの処理でそれらを呼び出すという形になると思います。
アクセスでいう標準モジュールです。

>「手続き定義」コマンドの主な用途もこれで推測
>がついたような気がします。(^^)v

イベント毎のプログラムは手続きそのものだと思います。

名札　閉じる　クリック時　　　　　　　　桐
　表　"メインメニュー"
　編集表　"部品マスタ"
　終了　表　編集対照表
手族き終了
　　　｜
Private Sub 閉じる_Click()　　　　　　アクセス
DoCmd.OpenForm stMenuname
DoCmd.Close acForm, "F部品マスタ"
End Sub

というかんじです。（中身はてきとうですよ）

>ところで２、ずっこけるようなことをお訊きしますが、例えば
>この「フォーカス取得」ってのは、どのように判断するのでし
>ょう？　ちょっと具体例みたいなものを挙げていただけるとう
>れしいのですが。(^^;)
>

イベントの判断はオブジェクト自身がするということです。
個々のオブジェクトが判断できるイベントの種類がイベントプロパティです。
個々のオブジェクト毎にそれぞれイベントの種類は違い、フォームには「開く」イベントはありますが、
「クリック時」のイベントはありません。
ボタンオブジェクトはその逆ですね。
例えば日付入力のテキストボックスがあるとし、カーソルが移動してきたらメッセージボックスを
出すとします。
開発者が定義画面で日付入力テキストボックスをポイントし右クリックすると、
属性（プロパティ）表が開きます。
そこには書式や色や高さの設定のほかにイベント属性もあります。
ここでフォーカス取得時をクリックするとイベント一括処理画面が開きます。
ここにはすでに

名札　日付入力　フォーカス取得
｜
手続き終了

とかかれ、開発舎はそこに処理を書きこむだけとなります。

現在の桐Ｖ７のコマンド群には、オブジェクト単位（特にテキストボックス）に実行させるような
こまかなコマンドがなく、行訂正、追加といった行単位処理が主流ですので具体的な例は
あまりだせませんが桐のイベントドリブン対応後の可能性の高さを楽しみにしています。
1405 Re: 悲しげ 1999/2/21-20:12
記事番号1400へのコメント
どもっ、はまださん、
お付き合いいただきありがとうございます。
大変タメになりました。
続編または他の方の予想も期待します。(^^)
1412 Re: 早く完成したい 1999/2/22-11:07
記事番号1366へのコメント
>（「早く完成したい」さん、もうひとつの方も読んでね）(^^;)
ありがとうございます。
「解りました」、「出来ました」「結果はこうなりました」と、投稿したいのですがなにぶんにも、
ＰＣ歴は２年弱、「桐」歴は一ケ月。
何をどうしたらよいのか、解らないまま投稿した次第です（すみません）
とにかく関係投稿内容全て印字して今はニラメッコ、完成目標に頑張る予定です。
また、投稿内容に追いつける様頑張ります。
とにかく今は、ありがとうございます。

ＰＳ：「桐」は兄譲り
幅田さん、佐田さんご記憶にございますでしょうか、もとこの投稿見てましたら、その節は大変
お世話になったそうで、この場をお借りしお礼申し上げますと共に今後ともご指導のほど
お願いします。
当時兄は、「ボタン一つで出来そうなデータベース見つけた！
会社（超小企業、業種違いで4部門）の上司を口説き落とせそうだ」と、口癖に言っていました。

戻る