| 2016/06/24(Fri) 09:36:37 編集(投稿者) 2016/06/23(Thu) 21:21:54 編集(投稿者) 2016/06/23(Thu) 21:08:59 編集(投稿者) 2016/06/23(Thu) 21:06:47 編集(投稿者) 2016/06/23(Thu) 21:03:57 編集(投稿者) 2016/06/23(Thu) 17:39:17 編集(投稿者) 2016/06/23(Thu) 17:23:23 編集(投稿者) 2016/06/23(Thu) 17:21:15 編集(投稿者)
> イベントの深さはまだ体験していませんが、 > イベントの書き方にも フォームが多くなった場合の書き方もあるんでしょうね。
例えば、テキストボックスの[入力後]イベントでは、テキストの修正ぐらいのことしか出来ません。
だからこれではアプリケーションを作れません。
しかし、コマンドボタンの機能名:手続き実行 で
イベント処理( .kev )に記述した一般手続きを指定して、
一般手続きを実行するならば、一括処理と同等の事が出来ます。
※一括処理だけで実行可能なコマンドがありますが、これはDOS桐との互換のためのコマンドなので、 それが実行できなくても差し支えないです。
従って、フォームを開きさえすれば、すべての準備は出来上がっているのです。
つまり、一括処理のようにメインループをぐるぐる回す必要はないのです。
※ここが大違いで、手間が全然少なく、デバッグが容易です。
フォームを開けば準備OKというところが、フォームの機能+イベント処理の便利なところです。
フォームの機能+イベント処理でアプリケーションを作るということは、
フォームのコマンドボタンの機能名:手続き実行 を主に利用します。
編集に伴うさまざまなイベントがありますが、
テキストボックスに関するイベントは重要ですが、
それ以外の編集関係のイベントはほとんど利用する必要がありません。
というわけでイベントよりもコマンドボタンの方を利用することが多いのが実際の姿ですよ。
フォームから別のフォームを開くのも簡単です。
コマンドボタンの機能名:開く でオープンできます。
モーダルが良ければ、コマンドボタンの機能名:モーダルフォームでオープンできます。
※一般手続き(またはイベントハンドラ)からメソッドによってコマンドボタンを実行することも出来ます。
このように複数のフォームの連携も簡単に出来ますよ。
> フォーム数が多い場合だと一括のほうが全体見えていいような気がしますが。 これは慣れの問題です。
イベントに慣れた人からは、一括の方が全体が見にくいという意見を聞きますよ。
また、フォームの機能+イベント処理では、
修正する場合の対象範囲が限定されているので、見通しが非常によいですよ。
ただし、水を差すようで恐縮ですが、フォームの機能+イベント処理に慣れるには相当な時間が必要です。
|