桐質問掲示板 [One Topic All View / Re[11]: 追伸 / Page: 0]

(現在過去ログ91 を表示中)

[ 最新記事及び返信フォームをトピックトップへ ]

■13525 / inTopicNo.1)

　思うところにフォーカスを移動したいのだが・

□投稿者/ まさやん -(2022/08/28(Sun) 20:57:01)

2022/09/02(Fri) 09:44:51 編集(投稿者)
2022/08/28(Sun) 20:57:58 編集(投稿者)

いつもお世話になっております。

添付のファイルに関しての質問になりますよろしくお願いいたします。
桐9s　WIN10の環境です。

メインフォームから始めてもらって、支出帳開いてもらって
終端行の月をクリックしてもらって　月　日　を入力して
摘要を　選んで　金額を入力するイベントなんですが、

摘要項目を選ぶとき(右に摘要項目のフォームが出るフォーム)
金額の未定義の摘要をクリックして　元の支出帳に戻って　金額を入力して終了するときは　思う通りの　月にフォーカスが移ってこれはそれでいいのですが

摘要フォームに　金額を定義してある　摘要を選ぶときに
支出帳の金額を入力しないで　そのまま　月にフォーカスを移動して終わりにしたい・・　　ことができなくて悩んでました。

一括で組んでた時は　ある程度思う通りに　フォーカス移動できました。
その思いで　イベントでもできるのではと少し無理強いしてますが
そもそも無理なのか　別な方法でできるか　よろしくお願いいたします。

それぞれのイベント定義も　多分ここで定義するのかな　違うところかな・・
の状態で作ってみましたので色んな所で不適合があるかと思います。

すみませんがよろしくお願いいたします。

引用返信 [メール受信/OFF] 削除キー/

■13526 / inTopicNo.2)

　Re[1]: 思うところにフォーカスを移動したいのだが・

▲▼■

□投稿者/ ななーし -(2022/08/29(Mon) 14:45:37)

2022/08/29(Mon) 14:51:07 編集(投稿者)

こんにちは　ななーしです。解決できたようで何よりです。
私と違い、ものすごくゴリゴリに書いてあるので驚きながら初心者ながら質問・回答させて下さい。

概要のところはt摘要の入力時の操作で入力支援ボタンからモーダルフォーム呼び出しにして、選択行を&STRに記入して入力するのがスマートな気がします。そうすると未定義の差異にフォームが開いて選択入力⇒戻ってt摘要がアクティブとなり簡単になるかと思います。

コマンドボタンは手続き実行を選び、以下のようにすれば呼び出せます。
【以下コマンドボタン書き方】
手続き実行　CMD並べ替え

【イベントでの書き方】
手続き定義開始　CMD並べ替え()
　　　　　　　　　　メソッド呼び出し　戻り値 = &秒,@ﾌｫｰﾑ.描画禁止(1)
　　　　　　　　　　　　　　　　　　　並べ替え　{[行]}
　　　　　　　　　　　　　　　　　　　位置指定　行番号=E
　　　　　　　　　　　　　　　　　　　&フォーム行数=#ﾌｫｰﾑ属性(4)
　　　　　　　　　　　　　　　　メソッド呼び出し　@ﾌｫｰﾑ.明細番号設定(&フォーム行数)
　　　　　　　　　　　　　　　　メソッド呼び出し　@t月２.フォーカス設定()
　　　　　　　　　　メソッド呼び出し　戻り値 = &秒,@ﾌｫｰﾑ.描画禁止(0)
手続き定義終了

また、初期並び替えで年・月でソートしておいてグループ移動はコマンドボタンで
グループ指定　次
グループ指定　前
この2つの動作で月を移動することが可能です。

引用返信 [メール受信/OFF] 削除キー/

■13527 / inTopicNo.3)

　Re[1]: 思うところにフォーカスを移動したいのだが・

▲▼■

□投稿者/ まさやん -(2022/08/29(Mon) 14:46:18)

> 摘要フォームに　金額を定義してある　摘要を選ぶときに
> 支出帳の金額を入力しないで　そのまま　月にフォーカスを移動して終わりにしたい・・　　ことができなくて悩んでました。
>

支出帳の　175行目

else if([摘要]="")
　　　　　　　　　　　　　　　　&コード=[コード],&年=[年２]
　　　　　　　　　　　フォーム呼び出し　"摘要参照"
　　　　　　　　　　　
　　　　　　　　　　　　if([入力確認]>0)
　&昭和年=#条件選択([コード]=1,[入金金額],1,[出金金額])
&最大値=[項番],&分=[年２],&秒=[月２],&STR=#全角(#文字列(&秒)+"月")
　　　　　　　　　　　　　　　　　条件　(&最大値>0)　手続き実行　家計費更新()
　　　　　　　　　　　　　　　メソッド呼び出し　@t月２.フォーカス設定()
　　　　　　　　　　　メソッド呼び出し　@ﾌｫｰﾑ.更新モード設定(0)
　　　　　　　　　　　　　　　　　手続き実行　入力終了()
　　　　　　　　　　　　end

これが　t摘要フォーカス取得イベントにあったのですが
t日　のソース値更新　イベントに移して
その前後　それなりのコマンド書いて　やってみたら　思う通りになりました。

すみません　ちょっと置き場所変えてうまくいきました。
ので　解決済み　とさせていただきます。

見てくださった方ありがとうございました。

解決済み!

引用返信 [メール受信/OFF] 削除キー/

■13528 / inTopicNo.4)

　Re[2]: 思うところにフォーカスを移動したいのだが・

▲▼■

□投稿者/ まさやん -(2022/08/29(Mon) 14:59:29)

2022/08/29(Mon) 15:04:26 編集(投稿者)
2022/08/29(Mon) 15:03:16 編集(投稿者)

ななーしさん　ありがとうございます。
私の解決済のタイミングで　ななーしさんの　ご提案　ありがとうございます。

> 概要のところはt摘要の入力時の操作で入力支援ボタンからモーダルフォーム呼び出しにして、選択行を&STRに記入して入力するのが・・

>そうすると未定義の差異にフォームが開いて選択入力に戻ってt摘要がアクティブとなり簡単になるかと思います。

なるほど。

この支出帳の場合　摘要の　各項目の集計更新をするために
必ず右の　摘要フォームを　表示して　選ぶ必要があり
自動で表示されるような形式にしました。
それで　[日]　ソース値更新に　摘要が出るように変えたところうまくいきました。

あとで　別件で　　入力支援ボタン　試したみたいと思います。

> 手続き実行　CMD並べ替え
>
> 【イベントでの書き方】
> 手続き定義開始　CMD並べ替え()
> 　　　　　　　　　　メソッド呼び出し　戻り値 = &秒,@ﾌｫｰﾑ.描画禁止(1)
> 　　　　　　　　　　　　　　　　　　　並べ替え　{[行]}
> 　　　　　　　　　　　　　　　　　　　位置指定　行番号=E
> 　　　　　　　　　　　　　　　　　　　&フォーム行数=#ﾌｫｰﾑ属性(4)
> 　　　　　　　　　　　　　　　　メソッド呼び出し　@ﾌｫｰﾑ.明細番号設定(&フォーム行数)
> 　　　　　　　　　　　　　　　　メソッド呼び出し　@t月２.フォーカス設定()
> 　　　　　　　　　　メソッド呼び出し　戻り値 = &秒,@ﾌｫｰﾑ.描画禁止(0)
> 手続き定義終了

ありがとうございます。
今まで一括でくんできたのの、名残で書いちゃったりしたので
大変参考になります。
ありがとうございます。

解決済にしましたが
ここはこの方法がいいとか　ありましたら、
頁の許す限り
またアドバイスをお願い致します。

引用返信 [メール受信/OFF] 削除キー/

■13529 / inTopicNo.5)

　Re[2]: 思うところにフォーカスを移動したいのだが・

▲▼■

□投稿者/ まさやん -(2022/08/29(Mon) 15:15:21)

2022/08/29(Mon) 15:29:30 編集(投稿者)
2022/08/29(Mon) 15:15:52 編集(投稿者)

ありがとうございます。

そうですね。　この方法もありますね。

> また、初期並び替えで年・月でソートしておいてグループ移動はコマンドボタンで
> グループ指定　次
> グループ指定　前
> この2つの動作で月を移動することが可能です。

しかし　記帳していない　月も　あることを想定していました。
1月・３月　記帳済　　
２月のデータを　後で発見！　を　グループ追加でもいいのですが、

操作する初心者が　グループ追加するよりも
空ファイルで　表示されてた方が　記帳しやすいかと・・

で　この方式にしていました。

ありがとうございました。

因みに　[月]グループがあるので

[月]項目が　入力　いらないかと思われますが、
実は　支出帳以外のフォームと　他のイベント、はすべて同じ内容で
年金受給の方の　フォームも入力してもらっています。

入力内容は同じなのですが
年金の方は　　８月　９月　10月と　　一つのグループで3ケ月入力します。
イベント作成時に　共通でできるようにと　[月]項目を設けていました。

支出帳のイベント中の　　&パソコン名　で　区別して
あとすっかり同じ　ことをしてました。　

引用返信 [メール受信/OFF] 削除キー/

■13530 / inTopicNo.6)

　Re[3]: 思うところにフォーカスを移動したいのだが・

▲▼■

□投稿者/ ななーし -(2022/08/29(Mon) 15:21:46)

なるほど！入力フォームとしてグループ値を利用しているため、確かに未入力の月があると移動が面倒ですよね。
初心者ながら思ったことを発言してみましたので勉強になります！
（恥ずかしながらどっちが質問者やねん！になってないといいですが・・・）

引用返信 [メール受信/OFF] 削除キー/

■13532 / inTopicNo.7)

　Re[1]: 思うところにフォーカスを移動したいのだが・

▲▼■

□投稿者/ ONnoji -(2022/08/29(Mon) 15:38:44)

2022/08/29(Mon) 16:19:09 編集(投稿者)

> すみません　ちょっと置き場所変えてうまくいきました。
> ので　解決済み　とさせていただきます。
>
> 見てくださった方ありがとうございました。

もっと早く言ってよぉ～。(T T)

じっくり見ちゃいましたよ。　(ーー;)--------------> ※遠い目線

なので、感想を少々。

まず、関係ない部分はカットして欲しいですね。

つまり、支出帳.wfm と摘要参照.wfm と必要ファイルだけで良いんじゃないですかね。

言葉が悪いですが、アプリを丸投げされては見る方が大変ですよ。

ｐ．ｓ．

プログラムの作り方は自由です。

しかしながら、今回は私の率直な感想を書かせていただきます。m(__)m

私はＷｉｎ桐では一括処理でアプリケーションを作ったことがありません。※ＤＯＳ桐では一括処理はたくさん作りましたよ。

拝見したところ、ＤＯＳ桐の頃のようにＥｓｃキーで進行をキャンセルするユーザインタフェースなんですね。

また、明細部のテキストの上に透明なコマンドボタンを重ね置きするというトリッキーなデザインに驚愕しました。

確かに、透明なコマンドボタンを重ね置きするというデザインは効果的な場合がありますが、

まさか明細部のデータを入力するテキストボックスの上に透明なコマンドボタンがあるとは思いませんでした。
　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
この場合には、透明なコマンドボタンを用いずに、

［フォーム］の［オブジェクトの属性］の［編集対象表］タブの［許可作業］で、［行挿入］と［行訂正］のチェックをオフにする。

そして、表示モード以外に遷移する必要がある場合には、コマンドボタンの機能名、またはフォームの［更新モード設定］メソッドを実行する

というデザインが適していると思いますよ。

例えばテキストボックスの上でスペースバーを押したときを例にすると以下のようになります。

　（例）［キーダウン］イベントで更新モードを変更する

　　この例は、スペースキーが押されたら、項目訂正モードに遷移する。
　　説明を簡略にするために、拙作：VK_Framework を使用した例を示します。
　　※著者( ONnoji )注：VK_Framework は、INF_Framework 第3.2版の IPS_Framework に統合される予定です。

　　手続き定義開始　txtObjectName::ﾌｫｰｶｽ取得(文字列　&喪失オブジェクト名)

　　　手続き実行　VKprcEventKeyDownON( )
　　　手続き実行　VKprcKeyON( )
　　　手続き実行　VKprcKeySet( "ｽﾍﾟｰｽ", 1, "0", "メソッド呼び出し　@フォーム.更新モード設定( 8 )" )

　　手続き定義終了

　　手続き定義開始　txtObjectName::ﾌｫｰｶｽ喪失(文字列　&取得オブジェクト名)

　　　手続き実行　VKprcEventKeyDownOFF( )

　　手続き定義終了

キモは、［フォーム］の［オブジェクトの属性］の［編集対象表］タブの［許可作業］で、［行挿入］と［行訂正］のチェックをオフにすることですよ。

なお、［許可作業］はフォームをユーザが会話操作する時の制限であって、コマンド・メソッドを制限するものではありませんよ。
　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

ｐ．ｐ．ｓ．

最後になりますが、ＤＯＳ桐からの一括処理というのは［処理（プロセス）中心］のアプローチなんですよね。

だから、「目的のためには手段を選ばず」という感じで、ゴリゴリのコテンコテンのプログラムを書いても誰も気にしなかったのです。

しかし、［フォーム＋イベント処理］というのは、［フォーム（データ）中心］のアプローチなんだと思いますよ。

なので、「目的のためには手段を選ばず」ではなく、自然なフォームの操作性（操作の流れ）を生かして、

補助的に［コマンドボタン］と［イベントハンドラや一般手続き］を利用するのが良いと思います。

もちろん凝ればキリがありませんが、［イベントハンドラ］をたくさん使うことはまずありませんよ。

どちらかといえば非常に少ないと思います。

一括処理からイベント処理へと切り替えるのが難しいと感じる人は多いと思います。

それは、［処理（プロセス）中心］から［フォーム（データ）中心］という視点の移動が難しいからだと思います。

［フォーム（データ）中心］で行くのであれば、フォームのタイトルバーは表示しますし、［閉じる］ボタンも表示します。

なので、自然と［閉じる］ボタンが押されても困らないようなデザインをするようになりますよ。

引用返信 [メール受信/OFF] 削除キー/

■13533 / inTopicNo.8)

　Re[2]: 思うところにフォーカスを移動したいのだが・

▲▼■

□投稿者/ まさやん -(2022/08/29(Mon) 17:36:53)

2022/08/29(Mon) 17:38:05 編集(投稿者)

> じっくり見ちゃいましたよ。　(ーー;)--------------> ※遠い目線

じっくりみられましたかぁ。
でも見られてよかったです。

私も　イベント挑戦してるんですが、一括の形式が抜けなくて。
それでも　前から見れば　やや判ってきた面もあるし
もっとイベントライクな　方法あるんだろうなあって　思いながら作ってました。

> なので、感想を少々。
ありがとうございます。

> まず、関係ない部分はカットして欲しいですね。

すみません。
一部だけアップしても　途中で不具合が出て戸惑うのかなと思い全部上げた次第です。

> 言葉が悪いですが、アプリを丸投げされては見る方が大変ですよ。

はい。ありがとうございます。

> この場合には、透明なコマンドボタンを用いずに、
云々・・

そうですね。　何が何でも手っ取り早く・・みたいに作ってました。

アドバイスありがとうございます。
試してみます。

> 補助的に［コマンドボタン］と［イベントハンドラや一般手続き］を利用するのが良いと思います。

はい。

> もちろん凝ればキリがありませんが、［イベントハンドラ］をたくさん使うことはまずありませんよ。

はい。

> それは、［処理（プロセス）中心］から［フォーム（データ）中心］という視点の移動が難しいからだと思います。

> ［フォーム（データ）中心］で行くのであれば、フォームのタイトルバーは表示しますし、［閉じる］ボタンも表示します。
>
> なので、自然と［閉じる］ボタンが押されても困らないようなデザインをするようになりますよ。

はい　ありがとうございます。

よきアドバイスありがとうございます。
これからもよろしくお願いします。

引用返信 [メール受信/OFF] 削除キー/

■13537 / inTopicNo.9)

　Re[3]: 思うところにフォーカスを移動したいのだが・

▲▼■

□投稿者/ ONnoji -(2022/08/30(Tue) 15:49:06)

2022/08/30(Tue) 17:42:38 編集(投稿者)

> 概要のところはt摘要の入力時の操作で入力支援ボタンからモーダルフォーム呼び出しにして、選択行を&STRに記入して入力するのが・・
>
>そうすると未定義の差異にフォームが開いて選択入力に戻ってt摘要がアクティブとなり簡単になるかと思います。

↑上は、ななーしさんのご意見ですが、概要として入力支援ボタンを利用するアプローチに対して私もまったく同感です。

ただし、あくまでも概要として同意しているのであり、入力支援ボタンを利用するアプローチの詳細に関して同意しているわけではありません。

詳細の部分にやり方は人それぞれで色々でしょう。私は、ななーしさんのご提案の詳細に関して検討したワケではありません。

老婆心ながら・・・

ここはイベントでゴリゴリやるよりも、テキストボックスに入力支援ボタンを追加して、モーダルフォームにするのがベターだと思いますよ。

とにかく、イベントハンドラでゴリゴリではなく、
　　　　　・・・・・・・・・・・・・
テキストボックスが未入力ならば入力支援ボタンが実行されるというインターフェースがフォームらしいアプローチだと思います。
　　　　　　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

※詳しくは　[入力支援ボタン]オブジェクトのヘルプを参照

［処理（プロセス）中心］から［フォーム（データ）中心］への視点の移動というのはこういう所から地道に試されることをお勧めします。

もしも、今までの癖で頭の中でイベントハンドラでゴリゴリと発想したならば、「いや待てよ、フォームの機能にあるだろうか？」と考えてください。

ちなみに、一括処理が命で［処理（プロセス）中心］だった人は、案外とフォームの基本的な機能をご存じない場合がありますよ。

そうすれば、自然と［フォーム＋イベント処理］でのアプリ作りが無理のないものになりますよ。

―[入力支援ボタン]オブジェクトのヘルプ

　[入力支援ボタン]オブジェクト（フォーム）

[自動表示]
　　入力支援ボタンを付加したオブジェクトが入力状態になったときに、入力支援ボタンの機能を自動実行するかどうかを選びます。

　自動表示　選択肢
　しない　　入力支援ボタンの機能を自動実行しません。
　未定義時　ソースが未定義値のときに限り、入力支援ボタンの機能を自動実行します。
　常に表示　入力支援支援ボタンの機能を、常に自動実行します。

[自動終了]
　　入力支援ボタンの機能が実行終了したときに、オブジェクト内の値の編集を終了するかどうかの指定です。
　ONにすると値の編集を終了し、つぎのオブジェクトにフォーカスが移ります。
　OFFにするとオブジェクト内の値の編集を継続します。

引用返信 [メール受信/OFF] 削除キー/

■13538 / inTopicNo.10)

　（削除）

▲▼■

□投稿者/ -(2022/08/30(Tue) 17:42:18)

この記事は(投稿者)削除されました

引用返信 [メール受信/OFF] 削除キー/

■13539 / inTopicNo.11)

　Re[5]: 思うところにフォーカスを移動したいのだが・

▲▼■

□投稿者/ まさやん -(2022/08/30(Tue) 18:10:16)

2022/08/30(Tue) 18:14:10 編集(投稿者)

すみません。

ONnoji　さんのアドアイスに

自動入力するかどうか・・・・　と書いてあるじゃないですか。
　
しかも　解説図つきで・・　　赤丸つきで・・・　　(*ﾉωﾉ)　(;´д｀)

すみません。
納得しました。
支援ボタン　でやってみます。

よく読まないで　返信してすみませんでした。

引用返信 [メール受信/OFF] 削除キー/

■13540 / inTopicNo.12)

　Re[6]: 思うところにフォーカスを移動したいのだが・

▲▼■

□投稿者/ ONnoji -(2022/08/30(Tue) 18:20:01)

2022/08/30(Tue) 23:51:07 編集(投稿者)

これはあくまでも ONnoji の個人的な感想です。(^^ゞ

当然ですが、一括処理を得意にされたこと自体には何も問題はありませんよ。

しかし、ＤＯＳ桐時代の［プロセス（処理）中心］アプローチに慣れ親しんだ人からすると、

［フォーム(wfm/wfx)］というMS Windowsの［ウィンドウ］をベースにした、［フォーム＋イベント処理］というアプリケーションの開発スタイルは、

天と地ほどの違いがあって頭の切り替えが難しいと思います。

私の場合には、大昔の MS VB5/6 を一通りかじっていたので、桐ver.8 から［フォーム＋イベント処理］を始めました。

しかし、桐の一括処理的な思考から脱皮して、桐ver.8 から MS VB5/6 ライクな［フォーム＋イベント処理］を開始するのには、

頭の切り替えにそれなりの時間が必要でしたよ。

だから、所謂［イベントドリブン］なプログラミングが、イベントハンドラだけによるプログラミングだと勘違いしたこともあります。
　　　　　　　　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・・・・・・・・・・・・
でもね、イベントハンドラだけでは、アプリケーションは作れないんですよ。
　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

もちろん、何もかもすべてにイベントハンドラを搭載してゴリゴリにすれば、

アプリケーションが作れるかもと妄想できますが、実際にはそれは歪なアプローチなのだと思いますよ。

むしろ自然なアプローチは、［フォーム(wfm/wfx)］というMS Windowsの［ウィンドウ］を利用して、

［フォーム(wfm/wfx)］に用意されている［オブジェクトの属性］と［コマンドボタンの機能］を最大限に利用して、

それでもどうしても不足な部分があれば、それをイベントハンドラで補うというものだと思います。

そう、［イベントハンドラ」は表舞台の「歌舞伎役者」ではなくて、裏方の「黒子」なんですよ。ここが一括処理と正反対なところです。

なので、主役は「フォームとその機能」で、裏方が「イベントハンドラ・一般手続き」なんですよ。アハハha。

ｐ．ｓ．

↑上で、あくまでも ONnoji の個人的な感想を展開しました。

今回もう十分に ONnoji が思う所を書かせていただきました。

これ以上は耳にタコでしょう。(^^ゞ

これでおしまいです。

もしもご興味があれば、以下の拙作ｗｅｂページをどうぞ。

こちら
　↓
桐の釣魚大全のトップ日本語データベース桐10s 対応
http://silicon7565.html.xdomain.jp/

［桐のイベント処理の入門講座］と［桐のイベント処理の詳細な解説」他が用意してあります。

引用返信 [メール受信/OFF] 削除キー/

■13541 / inTopicNo.13)

　Re[7]: 思うところにフォーカスを移動したいのだが・

▲▼■

□投稿者/ ななーし -(2022/08/30(Tue) 19:46:05)

ななーしです。私も感想を書かせてもらいます。
今回、会社の一括処理プログラムをイベント処理のフォームアプリケーションへと変更し、一新しました。私自身も一括処理型も数年使って・編集もしているので一からは組んでませんが一括処理型の利点も多少理解してます。
今回、フォームアプリケーションとして開発するにあたり、ONnojiさん紹介の大全と以下のサイトを参考に学びました。
http://akome409102.html.xdomain.jp/

一括処理と違い、多くのことはコマンドボタンの機能で実現できるため、一番長いもので400行、多くは150行程度のイベント処理で作りました。（フォーム数でいうと20個くらいですが）一括処理のときは2000行×３だったメイン処理を各フォームに分割してコマンドボタンとイベント処理の手続きの名前を一緒にすることでどこにどのプログラムが動くかを簡素化できる点が優れていると思います。一括処理連携の場合、フォームを閉じたあと一括処理側でいくつか処理があったりします。これをフォームだけで完結しているため視野を限定でき、わかりやすくなります。

フォーム中心にすることのメリットとして上記のように可視化がしやすい点だと思います。これは外のローコード開発やノンプログラミング開発でも言えますが可視化が進むとあとから見たときわかりやすい、また誰が見てもわかりやすいコードになります。プログラム単位が小さくなるためです。またプログラムが小さいと流用がかなりしやすいのも良い点でした。

最後に初心者でいつもここの熟練者の皆様にお力を借りており、大変お世話になっております。今後ともよろしくお願いいたします。

引用返信 [メール受信/OFF] 削除キー/

■13542 / inTopicNo.14)

　Re[8]: 思うところにフォーカスを移動したいのだが・

▲▼■

□投稿者/ まさやん -(2022/08/30(Tue) 22:22:11)

2022/08/30(Tue) 22:23:03 編集(投稿者)

ありがとうございます。

>どこにどのプログラムが動くかを簡素化できる点が優れていると思います。
>一括処理連携の場合、フォームを閉じたあと一括処理側でいくつか処理があったりします。
>これをフォームだけで完結しているため視野を限定でき、わかりやすくなります。

はい。確かにそう思っていました。
え？　これだけで済むの？　って具合でした。

他の仕事との合間の組み立てですので
徐々に少しずつやっていきたいと思います。

今回もいっぱいありがとうございました。

引用返信 [メール受信/OFF] 削除キー/

■13543 / inTopicNo.15)

　追伸

▲▼■

□投稿者/ まさやん -(2022/08/31(Wed) 22:46:48)

みなさん
色々とアドアイスありがとうございます。

その後　支出帳　入力画面は　カード形式で　新たに作り
そこで入力し　決定で　支出帳に　行追加の方式にしました

また
テキストオブジェクトの上の　コマンドボタンを　廃止して
おかげさまでスッキリとなり　コマンド行は　約半分になりました

今まで　余計な行(余計な心配も)を　書いてましたね。
アップしたのが恥ずかしいくらいです。
が、おかげで色んなことまた知識にプラスすることができました

ありがとうございます。

ガチガチじゃなくなったような気がします。

引用返信 [メール受信/OFF] 削除キー/

■13549 / inTopicNo.16)

　Re[10]: 追伸

▲▼■

□投稿者/ ONnoji -(2022/09/01(Thu) 13:51:16)

2022/09/02(Fri) 10:50:28 編集(投稿者)
2022/09/01(Thu) 18:50:39 編集(投稿者)
2022/09/01(Thu) 14:15:41 編集(投稿者)

> その後　支出帳　入力画面は　カード形式で　新たに作り
> そこで入力し　決定で　支出帳に　行追加の方式にしました

・家計簿的なもの、つまりレコード・エントリー（新規登録）の頻度が少ないもの
・データのチェックが非常に厳しいもの

これらの場合には、レコード・エントリー（新規登録）用のフォーム（カード形式）を使う方がいいでしょうね。

しかし、納品・売上明細書発行などのレコード・エントリー（新規登録）の頻度が高いものの場合には、

・複数明細のフォーム（一覧表形式・伝票形式）を使う
・エントリー用の単一明細のフォーム（カード形式）＋表示用の複数明細のフォーム（一覧表形式・伝票形式）を上下に並べて使う

などが良いと思いますよ。

ただし、複数明細のフォーム（一覧表形式・伝票形式）において対話操作でレコード・エントリー（新規登録）を行う場合には、
いろいろと余計なことに気を使わなければなりませんので、
エントリー用の単一明細のフォーム（カード形式）＋表示用の複数明細のフォーム（一覧表形式・伝票形式）を
上下に並べて使うハイブリッドの方がメンテナンスし易いですよ。

　◇　◇　◇　◇　◇　◇

さて、コマンドボタンに関してですが、以下に私の個人的な感想を述べさせていただきます。

コマンドボタンを作って、［マウス左クリック］イベント・イベントハンドラを作ったとします。

この時、次のようなコマンドボタンだとすると、

　　オブジェクト名：cmdObjectName
　┌────────────────┐
　│機能名　　機能パラメータリスト　│　
　│1 なし　　　　　　　　　　　　　│
　│2 なし　　　　　　　　　　　　　│
　│3 なし　　　　　　　　　　　　　│
　│4 なし　　　　　　　　　　　　　│
　└────────────────┘

つまり、↑上のように機能名１～４まで「なし」であるならば、このコマンドボタンには何の機能も無いわけです。

つまり、機能名がオール"なし"のコマンドボタンだったら、

ラベルオブジェクトに［マウス左クリック］イベント・イベントハンドラを作ったって同じことなんです。

ラベルオブジェクトだって、罫線で［立体］を選び、マウスがダウンされたら罫線を［くぼみ］にして、
マウスポインタがアウトしたら［立体］に戻して、左クリックされたら［立体］に戻してという芸当は出来るのです。

つまり、機能名がオール"なし"のコマンドボタンというのは、他のオブジェクトでも十分代替が可能なのです。

したがって、機能名がオール"なし"のコマンドボタンって去勢されたコマンドボタンと言える代物になります。
　　　　　　　　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・・・・・
　◇　◇　◇　◇　◇　◇

じゃあ～どうするのか？というと、

　　オブジェクト名：cmdObjectName 　　　　　　　対応する一般手続き
　┌─────────────────┐
　│機能名　　　　機能パラメータリスト│
　│1 表示　　　　　　　　　　　　　　│　　　　手続き定義開始　cmdObjectNameClick( )
　│2 手続き実行　cmdObjectNameClick　│　　　　　：
　│3 なし　　　　　　　　　　　　　　│　　　　　：
　│4 なし　　　　　　　　　　　　　　│　　　　手続き定義終了
　└─────────────────┘

というように、［機能名：表示］で表示モードに遷移して、［機能名：手続き実行］で一般手続きを呼び出せばいいのです。

［機能名：表示］で表示モードに遷移すれば、更新モード設定(0)メソッドを記述する必要がなくなります。※手間が一つ減ります(^^ゞ

［機能名：手続き実行］で一般手続きを呼び出せば、［手続き定義開始 ... 手続き定義終了］を手書きするのが面倒ですが、

コマンドボタンから呼び出す時の一般手続きはイベントハンドラと同等なんです。
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

とかく「フォーム＋イベント処理」を始めたばかりの人は、コマンドボタンの［マウス左クリック］イベントを利用しますね。

しかし、それはコマンドボタンの機能名に気が付いていなかったり、［機能名：手続き実行］の存在を知らなかったり、

単に［一般手続き］を記述するのが面倒くさいだけだったりだと思います。
・・・・・・・・・・・・・・・・・・・・・・・

このようにせっかく便利な機能があるのに利用しないのは勿体ないと思いませんか？？？

　◇　◇　◇　◇　◇　◇

ところでコマンドボタンでは［マウス左クリック］イベント・イベントハンドラを絶対に使わないかというとそれは違います。

ただし、それは［Ctrl + マウス左クリック］［Shift + マウス左クリック］を利用する場合です。

この場合には、［マウス左クリック］イベントハンドラの引数：&フラグ/長整数の値を調べてCtrlかShiftを判定します。

でも、普通では［Ctrl + マウス左クリック］［Shift + マウス左クリック］は使わないでしょう。

なので、この場合限りといいう使い方と思ってください。

なお、詳しいことは拙作ｗｅｂページにまとめてありますので、ご興味があればご覧ください。

こちら
　↓
桐の釣魚大全のトップ > フォームアプリケーション教書　第１部
１２　コマンドボタン　［フォーム＋イベント処理］によるアプリケーション開発では［コマンドボタン］が重要な働きをします。
http://silicon7565.html.xdomain.jp/guide/guide_Part1.htm#section12

ｐ．ｓ．

なお、期間限定でコマンドボタン機能リスト.tbl を添付します。

添付ファイルは数日で削除しますのでダウンロードはお早めに願います。

引用返信 [メール受信/OFF] 削除キー/

■13553 / inTopicNo.17)

　Re[11]: 追伸

▲▼■

□投稿者/ まさやん -(2022/09/01(Thu) 18:38:02)

早速のアドバイスありがとうございます。

なるほど・・　でした。

> なお、期間限定でコマンドボタン機能リスト.tbl を添付します。
>
> 添付ファイルは数日で削除しますのでダウンロードはお早めに願います。

ありがとうございます

引用返信 [メール受信/OFF] 削除キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

HOME HELP 新規作成新着記事トピック表示ファイル一覧検索過去ログ

- Child Tree -
- Antispam Version -