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

ツリー一括表示

Nomal 更新を判定出来ますか? /困り犬 (23/07/10(Mon) 17:35) #13853 1688978115.txt/1KB
Nomal Re[1]: 更新を判定出来ますか? /ONnoji (23/07/10(Mon) 19:11) #13854
  └Nomal Re[2]: 更新を判定出来ますか? /困り犬 (23/07/11(Tue) 08:25) #13855 1689031505.zip/13KB
    ├Nomal Re[3]: 更新を判定出来ますか? /ONnoji (23/07/11(Tue) 10:12) #13856
    │└Nomal Re[4]: 更新を判定出来ますか? /困り犬 (23/07/11(Tue) 10:41) #13857
    │  └Nomal Re[5]: 更新を判定出来ますか? /ONnoji (23/07/11(Tue) 11:19) #13859
    │    └Nomal Re[6]: 更新を判定出来ますか? /困り犬 (23/07/11(Tue) 14:02) #13860
    │      └Nomal Re[7]: 更新を判定出来ますか? /ONnoji (23/07/11(Tue) 19:14) #13862
    │        └Nomal Re[8]: 更新を判定出来ますか? /困り犬 (23/07/12(Wed) 09:09) #13863 解決済み!
    │          └Nomal Re[9]: 更新を判定出来ますか? /ONnoji (23/07/12(Wed) 10:15) #13864
    │            └Nomal Re[10]: 更新を判定出来ますか? /ONnoji (23/07/12(Wed) 15:24) #13865
    │              └Nomal Re[11]: 更新を判定出来ますか? /困り犬 (23/07/12(Wed) 17:07) #13866
    │                └Nomal Re[12]: 更新を判定出来ますか? /ONnoji (23/07/12(Wed) 18:03) #13867
    │                  └Nomal Re[13]: 更新を判定出来ますか? /困り犬 (23/07/13(Thu) 08:56) #13868
    │                    └Nomal Re[14]: 更新を判定出来ますか? /ONnoji (23/07/13(Thu) 10:30) #13869
    │                      └Nomal Re[15]: 更新を判定出来ますか? /困り犬 (23/07/13(Thu) 11:31) #13870
    │                        └Nomal Re[16]: 更新を判定出来ますか? /ONnoji (23/07/13(Thu) 14:27) #13871
    │                          └Nomal Re[17]: 更新を判定出来ますか? /困り犬 (23/07/13(Thu) 16:43) #13872
    │                            └Nomal Re[18]: 更新を判定出来ますか? /ONnoji (23/07/14(Fri) 11:44) #13873
    │                              └Nomal Re[19]: 更新を判定出来ますか? /困り犬 (23/07/14(Fri) 16:45) #13874
    │                                └Nomal Re[20]: 更新を判定出来ますか? /ONnoji (23/07/14(Fri) 17:21) #13875
    │                                  └Nomal Re[21]: 更新を判定出来ますか? /ONnoji (23/07/14(Fri) 18:16) #13877
    │                                    └Nomal Re[22]: 更新を判定出来ますか? /困り犬 (23/07/15(Sat) 09:06) #13878
    │                                      └Nomal Re[23]: 更新を判定出来ますか? /ONnoji (23/07/15(Sat) 09:17) #13879
    │                                        └Nomal Re[24]: 更新を判定出来ますか? /困り犬 (23/07/15(Sat) 10:41) #13880
    │                                          └Nomal Re[25]: 更新を判定出来ますか? /ONnoji (23/07/15(Sat) 11:17) #13881
    │                                            └Nomal Re[26]: 更新を判定出来ますか? /困り犬 (23/07/15(Sat) 11:54) #13882
    │                                              └Nomal Re[27]: 更新を判定出来ますか? /ONnoji (23/07/15(Sat) 12:11) #13884
    │                                                └Nomal Re[28]: 更新を判定出来ますか? /困り犬 (23/07/15(Sat) 13:37) #13885
    └Nomal Re[3]: 更新を判定出来ますか? /尾形 (23/07/11(Tue) 11:01) #13858
      └Nomal Re[4]: 更新を判定出来ますか? /困り犬 (23/07/11(Tue) 14:04) #13861


親記事 / ▼[ 13854 ]
■13853 / 親階層)  更新を判定出来ますか?
□投稿者/ 困り犬 -(2023/07/10(Mon) 17:35:15)
    桐10s Windows10 使用しています。

    質問です。

    添付ファイルの

    項目 製品長(数値) と 項目 製品幅(数値) の情報を更新した時のみ

    更新日(日時) を今日の日付に変更する事は可能でしょうか?

    条件選択で出来る様な気もしますが、関数を調べてみても項目を更新したと判定させる式があるように思いませんでした。

    現状は 更新日の項目計算式に #日時値を入れています。

    すみませんが、知恵を授けて欲しいです。

1688978115.txt
/1KB
[ □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13853 ] / ▼[ 13855 ]
■13854 / 1階層)  Re[1]: 更新を判定出来ますか?
□投稿者/ ONnoji -(2023/07/10(Mon) 19:11:47)
    2023/07/10(Mon) 22:38:44 編集(投稿者)

    > 更新日   型式 材質  フルート 製品長 製品幅 製品深
    > 2023/7/10 A  K5×K5 AF      900   600   730
    > 2023/7/10 A  K5×K5 AF      900   600   730
    > 2023/7/10 A  K5×K5 AF      900   600   730
    > 2023/7/10 A  K5×K5 AF     1000   650   730
    > 2023/7/10 A  K5×K5 AF     1000   650   730
    > 2023/7/10 A  K5×K5 AF     1000   650   730
    >
    > 項目 製品長(数値) と 項目 製品幅(数値) の情報を更新した時のみ
    > 更新日(日時) を今日の日付に変更する事は可能でしょうか?

    可能だと思いますよ
    しかし、表(.tbx)の項目計算式では無理だと思いますよ。
    フォーム+イベント+表(.tbx)で簡単に実現できると思います。

    > すみませんが、知恵を授けて欲しいです。

    もしも、説明だけで済むのであれば説明しますが、
    貴殿がフォーム+イベント+表(.tbx)に慣れていない場合には、当方の説明をご理解いただけません。

    よろしければ簡単なサンプルを作りますので、表の枠組みを書き出して、添付ファイルしてください。

    メニューバーの[ファイル]メニュー→[書き出し]→[表の枠組み]で、
    ファイル名を 元の表名+"枠組み" のようにして書き出したものを zip形式のファイルで添付してください。

    p.s.

    > 現状は 更新日の項目計算式に #日時値を入れています。

    ↑これは具合悪いですよ。
    何故ならば、項目計算式を再計算した時、#日時値に置き換わってしまいます。
          ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    つまり、項目計算式を再計算した時に、すべて(または、選択されている)のレコードがその日なってしまいますので、
    普通はそういう設定はしませんよ。
    従って、[更新日]は項目計算式ではなくて、普通の項目にして[挿入初期値式]に#日時値を設定してください。
                         ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    もしも、説明がピンとこない場合には次のように考えてみてください。

    例えば、[金額]という項目の項目計算式が [単価]×[数量] だったとすれば、項目計算式を再計算しても結果は変わりません。
    しかし、[更新日]という項目の項目計算式が #日時値 だったとすると、項目計算式を再計算すると結果は変わってしまいます。

    「[更新日]は項目計算式ではなくて、普通の項目にして[挿入初期値式]に#日時値を設定してください。」
    ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
     ↑
    という意味はそういうことなんですよ。

    つまり、#日時値のように日々変化する値を項目計算式にするのは不都合な場合があるので避けるものなのでありました。
        ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13854 ] / ▼[ 13856 ] ▼[ 13858 ]
■13855 / 2階層)  Re[2]: 更新を判定出来ますか?
□投稿者/ 困り犬 -(2023/07/11(Tue) 08:25:05)
    No13854に返信(ONnojiさんの記事)
    返信ありがとうございます。

    > p.s.
    >
    >>現状は 更新日の項目計算式に #日時値を入れています。
    >
    > ↑これは具合悪いですよ。
    > 何故ならば、項目計算式を再計算した時、#日時値に置き換わってしまいます。

    そうなんです・・・
    これが都合悪くて、特定の項目を更新した時に更新日が当日にならないかな?
    と思いました。

    編集初期値も考えたのですが、私じゃない人が表を更新するので、自動で更新日を更新して欲しいとリクエストがあったもので試案していたところです。

    宜しくお願いします。

1689031505.zip
/13KB
[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13855 ] / ▼[ 13857 ]
■13856 / 3階層)  Re[3]: 更新を判定出来ますか?
□投稿者/ ONnoji -(2023/07/11(Tue) 10:12:46)
    2023/07/11(Tue) 10:58:02 編集(投稿者)

    > >>現状は 更新日の項目計算式に #日時値を入れています。
    >>
    >>↑これは具合悪いですよ。
    >>何故ならば、項目計算式を再計算した時、#日時値に置き換わってしまいます。
    >
    > そうなんです・・・
    > これが都合悪くて、特定の項目を更新した時に更新日が当日にならないかな?
    > と思いました。
    >
    > 編集初期値も考えたのですが、私じゃない人が表を更新するので、自動で更新日を更新して欲しいとリクエストがあったもので試案していたところです。


    表の枠組みを受領しました。※もう不要ですので記事:13855の[編集]投稿画面で添付ファイルは削除していただいて結構です。

    当方の作業に入る前に確認しておきたいことがありますので以下に示します。

    ■[更新日]の項目計算式を削除してください。

     番号 項目名     データ型 項目計算式 挿入初期値式
      01 更新日     日時   #日時値
                      ↑
                      削除

     理由ですが、計算項目というのは手入力できない項目という意味です。
    ということは、イベント処理によって値を変更しようとしてても値変更できないのです。

    この項目は[挿入初期値式]に#日時値を設定してください。

     番号 項目名     データ型 項目計算式 挿入初期値式
      01 更新日     日時         #日時値
                            ↑
                           ここ!

    こうすれば、新規に行追加(行挿入)した時に自動的に #日時値 の値が入力されています。
    つまり、新規登録時には手間いらずで入力されるということです。

    ■項目が非常に多いので・・・(^^ゞ

    > しかし、表(.tbx)の項目計算式では無理だと思いますよ。
    > フォーム+イベント+表(.tbx)で簡単に実現できると思います。

    ↑と書きましたが、表の項目数が69個もあるんですね。

    入手した[表の枠組み]を拝見すると項目が多すぎて画面に表示しきれないので、[表示段数]が5段になっていますね。

    実際にオペレータさんが表(.tbx)を開いてデータを入力する時にも[表示段数]が5段でしょうか??

    なぜこんな質問をするかというと、(一覧表形式の)フォームには[表示段数]というのがありません。
    つまり、[表示段数]の表示というのは出来ないのです。

    そこで、当方は左側から何個かの項目を列固定して、項目を左右にスクロールするタイプの(一覧表形式の)フォームを提案いたします。
           ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    でも、貴殿またはオペレータさんが、それは嫌ということならばサンプルを作る意味がありませんので、当方に提案は取り下げます。
       ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    その場合には、代案としてイベント処理の概要の説明をしてサンプルは作成いたしません。

    当方の提案にご同意されますか?、お手数ですがご返信ください。

    p.s.

    > なぜこんな質問をするかというと、(一覧表形式の)フォームには[表示段数]というのがありません。

    フォームでの入力の途中で、どうしても[表示段数]を見たくなったら、[表編集]へ切り替えるメニューまたはボタンを実行すれば表編集になります。
    元のフォーム編集に戻すのもメニュー操作かボタン操作で簡単にできます。
    なので、そんなに問題はないかもしれませんね。アハハha(^^ゞ





[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13856 ] / ▼[ 13859 ]
■13857 / 4階層)  Re[4]: 更新を判定出来ますか?
□投稿者/ 困り犬 -(2023/07/11(Tue) 10:41:54)
    No13856に返信(ONnojiさんの記事)

    > この項目は[挿入初期値式]に#日時値を設定してください。
    >
    >  番号 項目名     データ型 項目計算式 挿入初期値式
    >   01 更新日     日時         #日時値
    >                         ↑
    >                        ここ!
    >
    はい。そうします。



    > そこで、当方は左側から何個かの項目を列固定して、項目を左右にスクロールするタイプの(一覧表形式の)フォームを提案いたします。
    >        ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    >
    > でも、貴殿またはオペレータさんが、それは嫌ということならばサンプルを作る意味がありませんので、当方に提案は取り下げます。
    >    ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    むしろONnojiさんの提案が良いです。
    私にしても、オペレーターにしても列固定が嫌という事は有りません。
    私としては知らないやり方を教えて貰える方が嬉しいです。


    > p.s.
    >
    >>なぜこんな質問をするかというと、(一覧表形式の)フォームには[表示段数]というのがありません。
    >
    > フォームでの入力の途中で、どうしても[表示段数]を見たくなったら、[表編集]へ切り替えるメニューまたはボタンを実行すれば表編集になります。
    > 元のフォーム編集に戻すのもメニュー操作で簡単にできます。
    > なので、そんなに問題はないかもしれませんね???(^^ゞ
    >
    確かに何かあれば表に戻れば良いので問題ないと思います!

    P.S.

    削除キー設定をしていなかったので記事:13855の添付ファイルは削除出来ませんでした。
    特に見られて問題のある表ではないので良いですが、掲示板のサーバーに負担をかけますよね・・・

    以後削除キーを設定して投稿します。
[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13857 ] / ▼[ 13860 ]
■13859 / 5階層)  Re[5]: 更新を判定出来ますか?
□投稿者/ ONnoji -(2023/07/11(Tue) 11:19:56)
    2023/07/11(Tue) 12:57:11 編集(投稿者)

    >>そこで、当方は左側から何個かの項目を列固定して、項目を左右にスクロールするタイプの(一覧表形式の)フォームを提案いたします。
    >>でも、貴殿またはオペレータさんが、それは嫌ということならばサンプルを作る意味がありませんので、当方に提案は取り下げます。
    >
    > むしろONnojiさんの提案が良いです。
    > 私にしても、オペレーターにしても列固定が嫌という事は有りません。
    > 私としては知らないやり方を教えて貰える方が嬉しいです。

    素早い返信ありがとうございます。

    > 確かに何かあれば表に戻れば良いので問題ないと思います!

    そうですね。
    表編集にもそれなりの便利さがあるものですね。
    でも、表編集ではプログラミングが出来ないんですよ。
    なのでフォームの出番という事になります。

     ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇

    69項目もあるので、既存の拙作のフォームをカスタマイズする方向でいきたいと思います、

    ■拙作をダウンロードする

    お手数ですが、【多遊】さんのHPの[観験桐]というダウンロードコーナ―で、

    #204 INF_Framework 第3.3版 改訂版(MkII) 基本セット for 桐10s / 桐sSL をダウンロードしてください。

    ダウンロードの方法は以下の拙作webページをお読みください。

     桐の釣魚大全のトップ > INF_Framework入門 レベル1
     http://silicon7565.html.xdomain.jp/INF_Framework/INF_Framework_Level_01.html

    ■オートフォームで 要領書.tbx を使ってみてください。

     > 4.オートフォームで任意の表を開きましょう
     >
     >  ■方法1
     >
     >  手順1.まず最初に[ファイル]メニュー → [開く]を選び、[開く]ダイアログで、"FW_オートINF_Framework_MkII.wfx"を選び[開く]ボタンを実行します。
     >      ※[開く]ダイアログでは[ファイルの種類]でフォーム(*.wfx;*.wfm)を選びます。

    桐の釣魚大全のトップ > INF_Framework入門 レベル1 を参考にして 要領書.tbx を開いてみてください。

    当方が提案するフォームはこのようなものです。

    列固定も出来ます。※左から9項目まで
    そして、項目の表示幅もマウスドラッグで変更できますよ。(^^ok
    詳しくは拙作webページの
    7.オートフォームの特長を確認しましよう
    をお読みください。

    p.s.

    追って、当方がカスタマイズしたフォームを添付します。

    > 項目 製品長(数値) と 項目 製品幅(数値) の情報を更新した時のみ
    > 更新日(日時) を今日の日付に変更する

    この要件でよろしいでしょうか??

    ご返信願います。


[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13859 ] / ▼[ 13862 ]
■13860 / 6階層)  Re[6]: 更新を判定出来ますか?
□投稿者/ 困り犬 -(2023/07/11(Tue) 14:02:42)
    No13859に返信(ONnojiさんの記事)
    > #204 INF_Framework 第3.3版 改訂版(MkII) 基本セット for 桐10s / 桐sSL をダウンロードしてください。
    >
    > ダウンロードの方法は以下の拙作webページをお読みください。
    >
    >  桐の釣魚大全のトップ > INF_Framework入門 レベル1
    >  http://silicon7565.html.xdomain.jp/INF_Framework/INF_Framework_Level_01.html
    >
    > ■オートフォームで 要領書.tbx を使ってみてください。

    ダウンロードして開いてみました。
    フォームなのに表の様な見た目にビックリしています。



    > 詳しくは拙作webページの
    > 7.オートフォームの特長を確認しましよう
    > をお読みください。
    >
    読んで勉強します!

    > p.s.
    >
    > 追って、当方がカスタマイズしたフォームを添付します。
    >
    >>項目 製品長(数値) と 項目 製品幅(数値) の情報を更新した時のみ
    >>更新日(日時) を今日の日付に変更する
    >
    > この要件でよろしいでしょうか??
    >
    はい。その要件で合っています。

    宜しくお願いします。
[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13860 ] / ▼[ 13863 ]
■13862 / 7階層)  Re[7]: 更新を判定出来ますか?
□投稿者/ ONnoji -(2023/07/11(Tue) 19:14:06)
    2023/07/12(Wed) 15:19:11 編集(投稿者)

    > ダウンロードして開いてみました。
    > フォームなのに表の様な見た目にビックリしています。

    拙作:オートフォームは出来る限り表に似たスタイルを追求したフォームです。
    というわけで、オートフォームと表を行き来しても違和感が無いと思いますよ。

     ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇

    カスタマイズが完成しました。

    ■ステップ1

    添付ファイルを解凍すると、次の2つのファイルがあります。

     要領書.wfx
     要領書.kex

    フォームの編集対象表は 要領書.tbx に設定してありますので、
    この2つのファイルを、 要領書.tbx が存在するフォルダに解凍してください。

    ■ステップ2

     すでにダウンロードした拙作のフォルダにある次のファイルを、
    要領書.tbx が存在するフォルダへコピーしてください。

     INF_Framework.cmx
     INF_MNU.kex
     INF_MNU.wfx
     IPS_Framework.cmx

    ※↑これらのファイルが無いと 要領書.wfx は正しく動作しません。

    以上の操作で、要領書.wfx が使えるようになります。

    なお、以下のコマンドボタンはワークスペースに移動して使えないようにしてあります。

    [表示条件の読み込み][表示する項目を選択][表示条件の登録][表示条件の削除][許可作業]

    これは、オペレータさんが誤ってコマンドボタンを実行してしまって戸惑わないようにするための処置です。
        ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    p.s.

    当方で十分テストした(つもり)ですので、問題なく動くと思いますが、貴殿に動作の確認をお願いします。

    もしも、具合が悪い事があればお早めにご連絡ください。

    p.p.s.

    拙作をダウンロードしていただいてありがとうございます。m(__)m

    拙作のオートフォームは面白いでしょう。
    たぶん気に入っていただけると思います。

    しかし、表ではなくてフォームという理由だけで敬遠する人も多いんですよ。アハハha。
    また、他人が作った物はどうも信用できないと利用に慎重な人も多いのです。
    ということで、私が知っている限りでは、貴殿は8番めくらいの希少なご利用者ですよ。

    p.p.p.s.

    用事が済んだので添付ファイルは削除しました。


[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13862 ] / ▼[ 13864 ]
■13863 / 8階層)  Re[8]: 更新を判定出来ますか?
□投稿者/ 困り犬 -(2023/07/12(Wed) 09:09:07)
    No13862に返信(ONnojiさんの記事)

    早速のご対応ありがとうございます。

    >>ダウンロードして開いてみました。
    >>フォームなのに表の様な見た目にビックリしています。
    >
    > 拙作:オートフォームは出来る限り表に似たスタイルを追求したフォームです。
    > というわけで、オートフォームと表を行き来しても違和感が無いと思いますよ。

    ちょっとダウンロードして使ってみての感想です。
    ONnojiさんの公開されているオートフォームの方が、表を直接使うよりも便利だと実感しています。

    今の自分の理解では、要領書の項目が多く この時はこのフォーム この時はこのフォーム と3種類位入力専用フォームを作って対応しようと思っていました。

    しかし、オートフォームでは 表示条件の登録 昨日があるので、条件を登録したら1つのフォームだけを使用して入力が出来ると思いました。
    (1つのフォームと言っても実際は色んな wfx kex cmx が一つのファイルに無いと正しく動かないのでしょうが・・・。今の自分のレベルでは到底理解の届かないファイルですが使用する事は出来るので使わせて貰います!)
    >
    > p.s.
    >
    > 当方で十分テストした(つもり)ですので、問題なく動くと思いますが、貴殿に動作の確認をお願いします。
    >
    > もしも、具合が悪い事があればお早めにご連絡ください。

    全く問題なく作動しました!
    本当に有難うございました!
    >
    > p.p.s.
    >
    > 拙作をダウンロードしていただいてありがとうございます。m(__)m
    >
    > 拙作のオートフォームは面白いでしょう。
    > たぶん気に入っていただけると思います。
    >
    > しかし、表ではなくてフォームという理由だけで敬遠する人も多いんですよ。アハハha。
    > また、他人が作った物はどうも信用できないと利用に慎重な人も多いのです。
    > ということで、私が知っている限りでは、貴殿は8番めくらいの希少なご利用者ですよ。
    >
    私もフォームはあまり好きではありませんでした(過去形)
    理由はフォームを使わないといけない設計になっている事自体が問題だと思っていたからです。

    しかし、要領書を作った時 項目を絞っても人生初の項目数になっていまったので
    設計自体を簡略化 単純化 する事が出来ない事もあるなと体感しました。

    そこで  ONnojiさんのオートフォームの存在をしり感動している所です。
    表の様な見た目なのに、表より便利という所が素晴らしいです。


    今回の質問は解決済み!です。

    オートフォームに関して知りたい事が出来たらまた新しく質問します。
    (オートフォームの事はこの掲示板で質問していいのか分かりませんが・・・)

    今回は本当にありがとうございました!
解決済み!
[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13863 ] / ▼[ 13865 ]
■13864 / 9階層)  Re[9]: 更新を判定出来ますか?
□投稿者/ ONnoji -(2023/07/12(Wed) 10:15:11)
    2023/07/12(Wed) 10:35:28 編集(投稿者)

    >>拙作:オートフォームは出来る限り表に似たスタイルを追求したフォームです。
    >>というわけで、オートフォームと表を行き来しても違和感が無いと思いますよ。
    >
    > ちょっとダウンロードして使ってみての感想です。
    > ONnojiさんの公開されているオートフォームの方が、表を直接使うよりも便利だと実感しています。

    フィードバックありがとうございます。感謝。m(__)m

    > 今の自分の理解では、要領書の項目が多く この時はこのフォーム この時はこのフォーム と3種類位入力専用フォームを作って対応しようと思っていました。
    > しかし、オートフォームでは 表示条件の登録 昨日があるので、条件を登録したら1つのフォームだけを使用して入力が出来ると思いました。
    > (1つのフォームと言っても実際は色んな wfx kex cmx が一つのファイルに無いと正しく動かないのでしょうが・・・。
    > 今の自分のレベルでは到底理解の届かないファイルですが使用する事は出来るので使わせて貰います!)

    誰でもフォームの中身を理解したいと思うハズです。
    何故ならば、ブラックボックスで使うのは気持ちが悪いからです。

    でも、利用するだけならばブラックボックスで良いハズでしょう。
    拙作は2003年12月公開以来、桐8から桐10s/桐sまで新しい桐が出る度に対応して、ずっと改良を重ねてきたアプリケーションです。
    なので、虫は少ないですよ。
    また、拙作は有志の方々にテストを十分していただいていますので品質に関してはご安心ください。(^^ok

    ちなみに、オートフォームは一覧表形式のフォームですが、同梱の INF_カード.wfx はカード形式のバージョンなんですよ。
    こちらもお試しいただくとよいかもしれません。
    同梱の 1st_INF_カード_説明書.txtを合わせてお読みください。
    ※その他の read_me 等のテキストファイルもざっと結構ですのでご一読ください。

    > 全く問題なく作動しました!
    > 本当に有難うございました!

    了解です。(^^)v

    >>しかし、表ではなくてフォームという理由だけで敬遠する人も多いんですよ。アハハha。
    >>また、他人が作った物はどうも信用できないと利用に慎重な人も多いのです。
    >>ということで、私が知っている限りでは、貴殿は8番めくらいの希少なご利用者ですよ。
    >>
    > 私もフォームはあまり好きではありませんでした(過去形)
    > 理由はフォームを使わないといけない設計になっている事自体が問題だと思っていたからです。

    項目数が少ないと表で足りちゃいますよね。
    でも、項目が多くなると大変です。
    これはフォームでも同じですが、フォームでは段表示できないから余計に敬遠しちゃいますよね。
    また、項目が多いとフォームを作るのが大変です。
    また、作ったのはいいけれど、直しがまた大変でウンザリしますよね。
    さらに、項目の幅が変更できないので使いにくいったら仕方ないと・・・etc.になりますね。
    だから、フォームなんか嫌い〜!となるんですよ。

    > しかし、要領書を作った時 項目を絞っても人生初の項目数になっていまったので
    > 設計自体を簡略化 単純化 する事が出来ない事もあるなと体感しました。
    >
    > そこで  ONnojiさんのオートフォームの存在をしり感動している所です。
    > 表の様な見た目なのに、表より便利という所が素晴らしいです。

    これまた嬉しいフィードバックをいただきましてありがとうございます。m(__)m
    そう!、実は表よりも便利なんですよ。
    これは秘密ですよ。ウソ。アハハha。

    > 今回の質問は解決済み!です。
    >
    > オートフォームに関して知りたい事が出来たらまた新しく質問します。
    > (オートフォームの事はこの掲示板で質問していいのか分かりませんが・・・)
    >
    > 今回は本当にありがとうございました!

    【多遊】さんのダウンロードコーナーで公開している作品なので、質問はOKですよ。(^^ok

    拙作に関しては、以下のwebページをご覧ください。

    ■桐の釣魚大全
     http://silicon7565.html.xdomain.jp/

    ■あこめの桐のプログラミング入門 桐10s by AKome
     http://akome409102.html.xdomain.jp/

    ちなみに、AKome さんは、拙作の初期バージョンからテストしてくださっている有志のお人です。

    p.s.

    改めて拙作に関して以下にご紹介します。(^^ゞ

    拙作は表とフォームを行き来しても違和感が無いようにデザインされています。
    拙作のフォームは最大100項目まで表示できます。
    拙作のフォームの項目幅、行の高さは変更できます。

    また、表に項目を追加・削除しても、フォームを変更する必要はありません。
    表に対応したフォームとして表示されます。
    そう、It's automatic。
    そして、まるで宇多田ヒカルちゃんのようにキュートです。ウソ。アハハha。

    拙作のオートフォームは一覧表形式ですが、伝票形式のスタイルに変更しても利用できます。
    なお、オートフォーム以外には、汎用ランチャー・神エクセルリーダー・イベント処理の整形ユーティリティもあります。

    以上で宣伝を終わります。(^^ゞ
    ご清聴ありがとうございます。m(__)m


[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13864 ] / ▼[ 13866 ]
■13865 / 10階層)  Re[10]: 更新を判定出来ますか?
□投稿者/ ONnoji -(2023/07/12(Wed) 15:24:22)
    > 項目 製品長(数値) と 項目 製品幅(数値) の情報を更新した時のみ
    > 更新日(日時) を今日の日付に変更する事は可能でしょうか?

    簡単に仕掛けを解説をします。

    よろしければご参考にしてください。

    <手続き一覧>

    名札 メイン

    cmdStartupClick

    txtField_24::入力前

    txtField_24::入力後

    └ prc項目値代入実行

    ■名札 メイン

      変数宣言 局所,文字列{ &mString }

     局所変数を1つ宣言しています。


    ■入力前と入力後のイベントハンドラ

     txtField_1::入力前/txtField_1::入力後 〜 txtField_100::入力前/txtField_100::入力後 とそれぞれ100個あります。
     コピペではなく事前に印字コマンドを利用してまとめて作ったものを読み込んだものです。

    以下の例はテキストオブジェクト:txtField_24 のイベントハンドラです。

    手続き定義開始 txtField_24::入力前(参照 文字列 &編集文字列)
     &mString = &編集文字列
     トレース出力 &this, " ", _&mString, " 入力前"
    手続き定義終了

    手続き定義開始 txtField_24::入力後(参照 文字列 &編集文字列,長整数 &モード,参照 長整数 &入力継続)
     トレース出力 &this, " ", _&mString, " ", _&編集文字列, " 入力後"
     手続き実行 prc項目値代入実行( &this, &mString, &編集文字列 )
    手続き定義終了

    手続き定義開始 prc項目値代入実行( 文字列 &objectName, 文字列 &lastString, 文字列 &nowString )
     変数宣言 自動,文字列{ &icon, &title = "prc項目値代入実行( )", &msg }
     変数宣言 自動,文字列{ &source }
     トレース出力 &title + " 引数:&objectName = " + &objectName + " 引数:lastString = " + &lastString + " 引数:&nowString = " + &nowString

     オブジェクト操作 &objectName{ &source = ソース }
     if ( &lastString <> &nowString )
      項目値代入 [更新日] = #日時値
      トレース出力 &title + " 項目名" + &source + " の値が変更されたので、[項目値代入 [更新日] = #日時値]を実行しました"
     else
      トレース出力 &title + " 項目名" + &source + " の値は変更されていません"
     end

    手続き定義終了

    ■開始時実行コマンドボタンから実行するプロシージャ

    手続き定義開始 cmdStartupClick( )
     変数宣言 自動,文字列{ &icon, &title = "cmdStartupClick( )", &msg }
     変数宣言 自動,文字列{ &objectName }
     変数宣言 自動,文字列{ &source }
     変数宣言 自動,整数 { &cnt }

     &msg = &EZWmFieldList1
     &icon = "i"
     **手続き実行 INFprcMsgPause( &icon, &title, &msg )

     &cnt = 1
     &objectName = #対応文字列( &EZWmFieldList1, &cnt )
     繰り返し ( &objectName <> #u )

      オブジェクト操作 &objectName{ &source = ソース }
      **トレース出力 _&cnt, " ", _&objectName, " ", _&source

      **トレース出力 " if ( &source = ""[製品長]"" .or &source = ""[製品幅]"" ) = " + #str( ( &source = "[製品長]" .or &source = "[製品幅]" ) )
      if ( &source = "[製品長]" .or &source = "[製品幅]" )

       オブジェクト操作 &objectName{ 入力前 = 1, 入力後 = 1 }
      end

      &cnt = &cnt + 1
      &objectName = #対応文字列( &EZWmFieldList1, &cnt )
     繰り返し終了

    手続き定義終了


[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13865 ] / ▼[ 13867 ]
■13866 / 11階層)  Re[11]: 更新を判定出来ますか?
□投稿者/ 困り犬 -(2023/07/12(Wed) 17:07:23)
    No13865に返信(ONnojiさんの記事)
    > 簡単に仕掛けを解説をします。
    >
    > よろしければご参考にしてください。

    せっかく作って頂いたので、貰いっぱなしは良くないと本日は

    FW_オートINF_Framework_MkII.kex と 要領書.kex の 差異を見ていました。

    ・要領書.kexには 2行目に 変数宣言 局所,文字列{ &mString }がある

    ・要領書.kexには 252行目 から 1296行目が追加してある(ここがカスタムして頂いた所ですよね?ありがたいです!)
    >
    > <手続き一覧>
    >
    > 名札 メイン
    >
    > cmdStartupClick
    >
    > txtField_24::入力前
    >
    > txtField_24::入力後
    > │
    > └ prc項目値代入実行
    >
    > ■名札 メイン
    >
    >   変数宣言 局所,文字列{ &mString }
    >
    >  局所変数を1つ宣言しています。
    >
    >
    > ■入力前と入力後のイベントハンドラ
    >
    >  txtField_1::入力前/txtField_1::入力後 〜 txtField_100::入力前/txtField_100::入力後 とそれぞれ100個あります。
    >  コピペではなく事前に印字コマンドを利用してまとめて作ったものを読み込んだものです。
    >
    > 以下の例はテキストオブジェクト:txtField_24 のイベントハンドラです。
    >
    > 手続き定義開始 txtField_24::入力前(参照 文字列 &編集文字列)
    >  &mString = &編集文字列
    >  トレース出力 &this, " ", _&mString, " 入力前"
    > 手続き定義終了
    >
    > 手続き定義開始 txtField_24::入力後(参照 文字列 &編集文字列,長整数 &モード,参照 長整数 &入力継続)
    >  トレース出力 &this, " ", _&mString, " ", _&編集文字列, " 入力後"
    >  手続き実行 prc項目値代入実行( &this, &mString, &編集文字列 )
    > 手続き定義終了
    >
    > 手続き定義開始 prc項目値代入実行( 文字列 &objectName, 文字列 &lastString, 文字列 &nowString )
    >  変数宣言 自動,文字列{ &icon, &title = "prc項目値代入実行( )", &msg }
    >  変数宣言 自動,文字列{ &source }
    >  トレース出力 &title + " 引数:&objectName = " + &objectName + " 引数:lastString = " + &lastString + " 引数:&nowString = " + &nowString
    >
    >  オブジェクト操作 &objectName{ &source = ソース }
    >  if ( &lastString <> &nowString )
    >   項目値代入 [更新日] = #日時値
    >   トレース出力 &title + " 項目名" + &source + " の値が変更されたので、[項目値代入 [更新日] = #日時値]を実行しました"
    >  else
    >   トレース出力 &title + " 項目名" + &source + " の値は変更されていません"
    >  end
    >
    > 手続き定義終了

    要領書.wfxの定義で txtField が100まであったので、式は txtField100 まであるのだろうと予想はできました。(書いてある内容は分からないのですが・・・)

    txtField24 までは連番であるのに、その次が100なので 25 から 99 はどうやって省けるのか不思議に感じたました。

    >
    > ■開始時実行コマンドボタンから実行するプロシージャ
    >
    > 手続き定義開始 cmdStartupClick( )
    >  変数宣言 自動,文字列{ &icon, &title = "cmdStartupClick( )", &msg }
    >  変数宣言 自動,文字列{ &objectName }
    >  変数宣言 自動,文字列{ &source }
    >  変数宣言 自動,整数 { &cnt }
    >
    >  &msg = &EZWmFieldList1
    >  &icon = "i"
    >  **手続き実行 INFprcMsgPause( &icon, &title, &msg )
    >
    >  &cnt = 1
    >  &objectName = #対応文字列( &EZWmFieldList1, &cnt )
    >  繰り返し ( &objectName <> #u )
    >
    >   オブジェクト操作 &objectName{ &source = ソース }
    >   **トレース出力 _&cnt, " ", _&objectName, " ", _&source
    >
    >   **トレース出力 " if ( &source = ""[製品長]"" .or &source = ""[製品幅]"" ) = " + #str( ( &source = "[製品長]" .or &source = "[製品幅]" ) )
    >   if ( &source = "[製品長]" .or &source = "[製品幅]" )
    >
    >    オブジェクト操作 &objectName{ 入力前 = 1, 入力後 = 1 }
    >   end
    >
    >   &cnt = &cnt + 1
    >   &objectName = #対応文字列( &EZWmFieldList1, &cnt )
    >  繰り返し終了
    >
    > 手続き定義終了

    今回は 数値 を更新した時 更新日を本日に変更して頂く物を作って頂きました。

    質問ですが、将来的に 文字列 を更新した時も 更新日を本日にしたい場合が出たときは

    変数宣言 自動,整数 { &cnt }



    &cnt = 1
    &objectName = #対応文字列( &EZWmFieldList1, &cnt )
    繰り返し ( &objectName <> #u )

    がキモになるんですかね?

    素人考えで申し訳ないです・・・

    自分としては、せっかく作って貰った物を何も考えずに使うよりは、分からないなりに考えてみたいので!



[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13866 ] / ▼[ 13868 ]
■13867 / 12階層)  Re[12]: 更新を判定出来ますか?
□投稿者/ ONnoji -(2023/07/12(Wed) 18:03:39)
    2023/07/12(Wed) 19:48:04 編集(投稿者)
    2023/07/12(Wed) 18:21:36 編集(投稿者)

    > ・要領書.kexには 2行目に 変数宣言 局所,文字列{ &mString }がある
    > ・要領書.kexには 252行目 から 1296行目が追加してある(ここがカスタムして頂いた所ですよね?ありがたいです!)

    イベントハンドラは、 254行めから1252行めでに記述した[手続き定義開始...手続き定義終了]です。
    合計200個あります。
    実は手で書いたわけでもコピペしたわけでもなく、プログラムを組んで作成したテキストを読み込んだものです。
    こういった単純な繰り返しは手操作で行うと必ずミスをするものなので・・・(^^ゞ

    1254行め〜1296行めの[手続き定義開始...手続き定義終了]は一般手続きです。

    > 要領書.wfxの定義で txtField が100まであったので、式は txtField100 まであるのだろうと予想はできました。(書いてある内容は分からないのですが・・・)
    >
    > txtField24 までは連番であるのに、その次が100なので 25 から 99 はどうやって省けるのか不思議に感じたました。

    フォーム明細部のオブジェクトは txtField1 〜 txtField24 までは横並びに配置していますが、txtField25 〜 txtField100 は重ねて配置しています。
    これは、全部横並びにするのは無駄だからです。

    拙作は、必要に応じて txtField25 〜 txtField100 を横並びに配置し直すように動作します。
    まぁ、この辺のことはご存じなくて構いませんけど・・・(^^ゞ

    > 今回は 数値 を更新した時 更新日を本日に変更して頂く物を作って頂きました。
    >
    > 質問ですが、将来的に 文字列 を更新した時も 更新日を本日にしたい場合が出たときは
    >
    > 変数宣言 自動,整数 { &cnt }
    >
    > と
    >
    > &cnt = 1
    > &objectName = #対応文字列( &EZWmFieldList1, &cnt )
    > 繰り返し ( &objectName <> #u )
    >
    > がキモになるんですかね?
    >
    > 素人考えで申し訳ないです・・・
    >
    > 自分としては、せっかく作って貰った物を何も考えずに使うよりは、分からないなりに考えてみたいので!

    項目のデータ型は関係ありません。キャレットが現れて書き換えられる項目ならばOKです。
                    ・・・・・・・・・・・・・・・・・・・・・・・

    例えば、項目の[使用木部コード]を追加したい場合には次のように書き換えてください。

    要領書.kex の 1287行めです。

    【改修前】 if ( &source = "[製品長]" .or &source = "[製品幅]" )

    【改修後】 if ( &source = "[製品長]" .or &source = "[製品幅]" .or &source = "[使用木部コード]" )

    なお、項目名は必ず半角の角かっこ( "[", "]" )で囲んでください。全角の角かっこでは駄目です。
       ・・・・・・・・・・・・・・・・・・・・・・・・・・・
    つまり、 if ( &source = "[項目名]" .or &source = "[項目名]" .or &source = "[項目名]" .or &source = "[項目名]" ) という要領です。

    今後はこれで貴殿の自力で改修できるハズですよ。

    なお、あまりにも項目名の数が多くなった場合には、別の書き方があるのでその際にお問い合わせください。


    p.s.

    > FW_オートINF_Framework_MkII.kex と 要領書.kex の 差異を見ていました。
    >
    > ・要領書.kexには 2行目に 変数宣言 局所,文字列{ &mString }がある
    >
    > ・要領書.kexには 252行目 から 1296行目が追加してある(ここがカスタムして頂いた所ですよね?ありがたいです!)

    ハイ!、ご明察です。

    ところで、FW_オートINF_Framework_MkII.kex の内容を見て気が付かれたと思いますが、
    たったの 253行で、しかも[名札 メイン]の部分しかありません。

    これって不思議に思われたかもしれませんね。
    タネ明かしをすると、もっとたくさんのプログラムが隠れているんですよ。

    隠れているプログラムというのは、

     INF_Framework.cmx
     IPS_Framework.cmx

    という2つのファイルに収められているプロシージャ(手続き)です。

    これは一括処理ではなく、イベント処理で利用するライブラリ(モジュール)です。

    イベントハンドラと一般手続きがギッシリ詰まったファイルですよ。

    これらのプロシージャ(手続き)は常に一斉にすべてが動くのではなくて、必要な時に必要なものだけが動くようになっています。

    元々、拙作はブラックボックスで使っていただくことを念頭にしていますので、見る必要がないものはすべて隠蔽しています。

    これは秘密を保つという意味ではなく、利用者が見たり理解する必要がないものは隠してしまうという意味です。
                      ・・・・・・・・・・・・・・・・・・・・・・・・・

    つまり、ブラックボックスで使うことが前提なので余計なものはお見せしないようになっているのです。
        ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    ということで、私は拙作をフレームワークと呼んでいます。

    フレームワークに関しては、拙作(桐の釣魚大全のトップ > ワークショップ)webページから重要なところを転載します。

      ■ハリウッドの原則
       フレームワークの性質を端的に表す良く知られた言葉として、ハリウッドの原則(Hollywood Principle)があります。
      これは「Don't call us. We'll call you.」で、
      本来は、「お電話は不要です。こちらからお掛けします」、という意味です。
      つまり、INF_Frameworkの利用者は、INF_Framework.cmdの内容を知っている必要がまったありません。
      もしも、問題があれば、INF_Framework 側からメッセージボックスでお知らせします。

       以前ある人から「INF_Tools_library.cmdは5000行を超える大作で、私には目も眩むようです。」
      というお言葉をいただいたことがあります。
      しかし、このような心配は一切不要なのです。
      Don't call us. We'll call you. > ALL

    ↑のように、拙作フレームワークには「ハリウッドの原則」が適用されるのだとご理解いただければ幸いです。(^^ゞ


[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13867 ] / ▼[ 13869 ]
■13868 / 13階層)  Re[13]: 更新を判定出来ますか?
□投稿者/ 困り犬 -(2023/07/13(Thu) 08:56:18)
    No13867に返信(ONnojiさんの記事)

    > フォーム明細部のオブジェクトは txtField1 〜 txtField24 までは横並びに配置していますが、txtField25 〜 txtField100 は重ねて配置しています。
    > これは、全部横並びにするのは無駄だからです。
    >
    > 拙作は、必要に応じて txtField25 〜 txtField100 を横並びに配置し直すように動作します。
    > まぁ、この辺のことはご存じなくて構いませんけど・・・(^^ゞ

    そんな事が出来ること自体初めて知りました!
    知らない事だらけです。

    > 項目のデータ型は関係ありません。キャレットが現れて書き換えられる項目ならばOKです。
    >                 ・・・・・・・・・・・・・・・・・・・・・・・
    >
    > 例えば、項目の[使用木部コード]を追加したい場合には次のように書き換えてください。
    >
    > 要領書.kex の 1287行めです。
    >
    > 【改修前】 if ( &source = "[製品長]" .or &source = "[製品幅]" )
    >
    > 【改修後】 if ( &source = "[製品長]" .or &source = "[製品幅]" .or &source = "[使用木部コード]" )
    >
    > なお、項目名は必ず半角の角かっこ( "[", "]" )で囲んでください。全角の角かっこでは駄目です。
    >    ・・・・・・・・・・・・・・・・・・・・・・・・・・・
    > つまり、 if ( &source = "[項目名]" .or &source = "[項目名]" .or &source = "[項目名]" .or &source = "[項目名]" ) という要領です。
    >
    > 今後はこれで貴殿の自力で改修できるハズですよ。

    何から何まで教えて下さりありがとうございます!
    その部分を追加する事なら私でも対応できそうです。
    本当にありがとうございます。

    >
    > なお、あまりにも項目名の数が多くなった場合には、別の書き方があるのでその際にお問い合わせください。
    >
    はい。お言葉に甘えて問い合わせさせて貰います。

    >
    > p.s.
    >
    >>FW_オートINF_Framework_MkII.kex と 要領書.kex の 差異を見ていました。
    >>
    >>・要領書.kexには 2行目に 変数宣言 局所,文字列{ &mString }がある
    >>
    >>・要領書.kexには 252行目 から 1296行目が追加してある(ここがカスタムして頂いた所ですよね?ありがたいです!)
    >
    > ハイ!、ご明察です。
    >
    > ところで、FW_オートINF_Framework_MkII.kex の内容を見て気が付かれたと思いますが、
    > たったの 253行で、しかも[名札 メイン]の部分しかありません。
    >
    > これって不思議に思われたかもしれませんね。

    はい。かなり不思議に思いました。

    > タネ明かしをすると、もっとたくさんのプログラムが隠れているんですよ。
    >
    > 隠れているプログラムというのは、
    >
    >  INF_Framework.cmx
    >  IPS_Framework.cmx
    >
    > という2つのファイルに収められているプロシージャ(手続き)です。

    最初 要領書の入ったファイルに

    FW_オートINF_Framework_MkII.kex
    FW_オートINF_Framework_MkII.wfx
    INF_Framework.cmx
    IPS_Framework.cmx

    を入れてフォームを開いてみたんですよ。
    そうしたら、出来ない事もあったので、一つずつファイルを追加していって
    全ての機能が使えるようになったので、これは複数のファイルで動いているんだなと気付きました。


    >   ■ハリウッドの原則
    >    フレームワークの性質を端的に表す良く知られた言葉として、ハリウッドの原則(Hollywood Principle)があります。
    >   これは「Don't call us. We'll call you.」で、
    >   本来は、「お電話は不要です。こちらからお掛けします」、という意味です。
    >   つまり、INF_Frameworkの利用者は、INF_Framework.cmdの内容を知っている必要がまったありません。
    >   もしも、問題があれば、INF_Framework 側からメッセージボックスでお知らせします。
    >
    そうですよね。そもそも理解出来ないし下手に何か変更してファイルが壊れたら元もこうもないですもんね(:_;)


    今回の件で、イベントやフォームに興味が出ました。
    ONnojiさんのホームページや、桐のヘルプにある一括処理・履歴・イベントを教材にして知識を深めていこうと思います!
[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13868 ] / ▼[ 13870 ]
■13869 / 14階層)  Re[14]: 更新を判定出来ますか?
□投稿者/ ONnoji -(2023/07/13(Thu) 10:30:07)
    2023/07/13(Thu) 10:36:43 編集(投稿者)

    >>つまり、 if ( &source = "[項目名]" .or &source = "[項目名]" .or &source = "[項目名]" .or &source = "[項目名]" ) という要領です。
    >>
    >>今後はこれで貴殿の自力で改修できるハズですよ。
    >
    > 何から何まで教えて下さりありがとうございます!
    > その部分を追加する事なら私でも対応できそうです。
    > 本当にありがとうございます。
    >
    >>
    >>なお、あまりにも項目名の数が多くなった場合には、別の書き方があるのでその際にお問い合わせください。
    >>
    > はい。お言葉に甘えて問い合わせさせて貰います。

    項目の追加は簡単ですね。

    当方は、[更新日]というデータが持つ意味がイマイチわからないのですが、
    レコード(行)の項目が書き換えられたらその日の日時にするですよね。

    だったら、[更新日]と計算項目を除いた項目が書き換えられたらば、となりそうなものですが?
    しかし、これだとケアレスミスでどんどん書き換わてしまいますね。

    拙作フレームワークのデフォルトでは、項目の値は範囲選択されていますから、
    表示モード以外で文字キーをちょっとでも押せば文字が上書きされてしまいます。

    フォームヘッダ部に3個並んでいる[ON/OFF]の一番右のボタンは、"項目値を範囲選択する"ものです。
    このボタンを押して "OFF"にすれば、項目の値は範囲選択されなくなりますよ。

    なお、現行では[製品長]と[製品幅]が書き換えられた時に[更新日]を変更していますが、
    その際に、メッセージを表示することも可能です。

    例えば、

     [製品長]が変更されました
     変更前:900
     変更後:901

     データを保存してよろしいですか?
     [はい] [いいえ]

    という具合です。

    しかし、こういうのは、うっかりで変更の場合には有効ですが、
        ・・・・・・・・・・・・・・・・・・・・・
    新規に行を追加(または挿入)する時には邪魔ですね。
    もちろん、追加(または挿入)する時には表示しない設定も可能です。

    > 新規に行を追加(または挿入)する時には邪魔ですね。

    一見すると便利な機能でも、入力の途中で[メッセージボックス]がお邪魔虫のように出現するのは、
    オペレータの入力のリズムの邪魔になります。
    ・・・・・・・・・・・・・・・・・・・・
    こういうのは、オペレータをイライラさせるだけで一利もありません。
    ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    ちなみに、ただ単にデータを一覧しているだけの状態、
    つまり表示モードなのに、うっかり項目訂正してしまった場合には有用ですね。
       ・・・・・・・・・・・・・・・・・・・・・・・・・

    なお、最初からF2キーを押して訂正モードに遷移している場合には、
    訂正する度に[メッセージボックス]がお邪魔虫になりますので、
    行追加(行挿入)と同じように表示しない方がいいですね。

    と、デザインに関してはいろいろと考えられますが、キリがないので・・・(^^ゞ

    > 最初 要領書の入ったファイルに
    >
    > FW_オートINF_Framework_MkII.kex
    > FW_オートINF_Framework_MkII.wfx
    > INF_Framework.cmx
    > IPS_Framework.cmx
    >
    > を入れてフォームを開いてみたんですよ。
    > そうしたら、出来ない事もあったので、一つずつファイルを追加していって
    > 全ての機能が使えるようになったので、これは複数のファイルで動いているんだなと気付きました。

    [スタック][表示条件の読み込み][表示する項目を選択][表示条件の登録][表示条件の削除][許可作業]

    ↑これらのボタンを実行する時に必要なファイルが存在しない場合、メッセージボックスでお知らせします。
    そう!、ハリウッドの原則です。アハハha。

    >>  ■ハリウッドの原則
    >>   フレームワークの性質を端的に表す良く知られた言葉として、ハリウッドの原則(Hollywood Principle)があります。
    >>  これは「Don't call us. We'll call you.」で、
    >>  本来は、「お電話は不要です。こちらからお掛けします」、という意味です。
    >>  つまり、INF_Frameworkの利用者は、INF_Framework.cmdの内容を知っている必要がまったありません。
    >>  もしも、問題があれば、INF_Framework 側からメッセージボックスでお知らせします。
    >>
    > そうですよね。そもそも理解出来ないし下手に何か変更してファイルが壊れたら元もこうもないですもんね(:_;)

    必要なファイルが存在しない場合以外にも、
    フォーム上に拙作フレームワークが必要とするオブジェクトや変数が存在しない場合にも、
    ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    [メッセージボックス]でお知らせします。

    > 今回の件で、イベントやフォームに興味が出ました。
    > ONnojiさんのホームページや、桐のヘルプにある一括処理・履歴・イベントを教材にして知識を深めていこうと思います!

    興味を持たれるのは結構ですが、[一括処理]と[履歴]はお勧めしません。
                   ・・・・・・・・・・・・・・・・・・・
    もちろん、それもいいですが、これらにはDOS桐の残滓的な部分がありますので、
                       ・・・・・・・・・・・・・・・・
    [フォーム+イベント+表]の理解の妨げになります。
    ・・・・・・・・・・・・・・・・・・・・・・・・

    特に一括処理とイベント処理では、[制御の反転]つまり動作原理や発想が真逆です。
      ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    ちなみに、多くに人がこのことに気が付いていないので、[一括処理]と[イベント処理]が水と油の関係のように思っていません。

    なので、順番よろしく、まず[履歴]と[一括処理]を勉強してから、次に[イベント処理]を勉強しようと思う人が多いのです。
    しかし、それでは[制御の反転]や[DOS桐の残滓的な部分]に遭遇して頭の中が混乱するだけです。
        ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    というわけで、私( ONnoji )は、桐でプログラミングのお勉強をされるのならば、
    [フォーム+イベント+表]による方法をだけをお勉強されることをお勧めします。
    ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・




[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13869 ] / ▼[ 13871 ]
■13870 / 15階層)  Re[15]: 更新を判定出来ますか?
□投稿者/ 困り犬 -(2023/07/13(Thu) 11:31:20)
    No13869に返信(ONnojiさんの記事)
    > 2023/07/13(Thu) 10:36:43 編集(投稿者)

    > だったら、[更新日]と計算項目を除いた項目が書き換えられたらば、となりそうなものですが?
    > しかし、これだとケアレスミスでどんどん書き換わてしまいますね。

    そうなんです・・・
    実はそれは最初に思い付いたのですが、何かの拍子に変更してしまっても更新日が変更されるなと思いその考えは止めました。

    >
    > なお、現行では[製品長]と[製品幅]が書き換えられた時に[更新日]を変更していますが、
    > その際に、メッセージを表示することも可能です。
    >
    > 例えば、
    >
    >  [製品長]が変更されました
    >  変更前:900
    >  変更後:901
    >
    >  データを保存してよろしいですか?
    >  [はい] [いいえ]
    >
    > という具合です。
    >
    > しかし、こういうのは、うっかりで変更の場合には有効ですが、
    >     ・・・・・・・・・・・・・・・・・・・・・
    > 新規に行を追加(または挿入)する時には邪魔ですね。

    確かに毎回メッセージが出てきたら効率下がりますよね。
    ストレスになると思います。

    >
    > [スタック][表示条件の読み込み][表示する項目を選択][表示条件の登録][表示条件の削除][許可作業]
    >
    > ↑これらのボタンを実行する時に必要なファイルが存在しない場合、メッセージボックスでお知らせします。
    > そう!、ハリウッドの原則です。アハハha。

    正にメッセージボックスを読んでファイルを追加したので、何が問題か教えてくれるのはありがたかったです!


    > 興味を持たれるのは結構ですが、[一括処理]と[履歴]はお勧めしません。
    >                ・・・・・・・・・・・・・・・・・・・

    現状の話をすると、私は履歴は嫌いなんです。
    ちょっとした履歴ならまだ許せます。
    凄い長い履歴だと何かあった時直すのも大変だし、そもそも前任者(在職者なら救いはあるのですが)が何故このような履歴にしたのか理解する所から始めないといけないので好きじゃありません。

    > [フォーム+イベント+表]による方法をだけをお勉強されることをお勧めします。
    > ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    >
    はい。フォーム+イベント+表 を勉強していきます!
[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13870 ] / ▼[ 13872 ]
■13871 / 16階層)  Re[16]: 更新を判定出来ますか?
□投稿者/ ONnoji -(2023/07/13(Thu) 14:27:16)
    2023/07/13(Thu) 14:47:44 編集(投稿者)

    >>だったら、[更新日]と計算項目を除いた項目が書き換えられたらば、となりそうなものですが?
    >>しかし、これだとケアレスミスでどんどん書き換わてしまいますね。
    >
    > そうなんです・・・
    > 実はそれは最初に思い付いたのですが、何かの拍子に変更してしまっても更新日が変更されるなと思いその考えは止めました。

    なるほどですね。

    >>なお、現行では[製品長]と[製品幅]が書き換えられた時に[更新日]を変更していますが、
    >>その際に、メッセージを表示することも可能です。
    >>
    >>例えば、
    >>
    >> [製品長]が変更されました
    >> 変更前:900
    >> 変更後:901
    >>
    >> データを保存してよろしいですか?
    >> [はい] [いいえ]
    >>
    >>という具合です。

    本当は項目訂正するつもりは無かったのに、うっかり項目訂正の場合にメッセージボックスを表示するものを作ってみましょうか?

    いかがでしょうか??

    ご返信ください。

    > 今の自分の理解では、要領書の項目が多く この時はこのフォーム この時はこのフォーム と3種類位入力専用フォームを作って対応しようと思っていました。
    > しかし、オートフォームでは 表示条件の登録 機能があるので、条件を登録したら1つのフォームだけを使用して入力が出来ると思いました。

    ↑このような使い方を考えていらっしゃる場合には、

     要領書.wfx の[表示条件の読み込み][表示する項目を選択][表示条件の登録][表示条件の削除][許可作業]を復活させなければなりませんが、
    その場合には、カスタマイズした内容の一部を変更する必要があります。

    要領書.wfxでも、条件を使うようにしますか??

    これも併せてご返信ください


    p.s.

    > 確かに毎回メッセージが出てきたら効率下がりますよね。
    > ストレスになると思います。

    表やフォームを作った人自身ならば、多少使いにくくても我慢できるものですね。
           ・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    それどころかメッセージボックスが表示された時に、自分のエラー対処の腕前にウットリして自画自賛するものなんですよ。

    しかし、オペレータさんはタマッタもんじゃないですよ。ホント、怒りますよね。アハハha。
    でも、このようなユーザ無視のデザインは非常に多いんですよ。


    > 現状の話をすると、私は履歴は嫌いなんです。

    私も[履歴]は大大大大嫌いですよ。※これは個人の感想です。アハハha。
    なので、[履歴]で作業をしたことがありませんよ。

    > ちょっとした履歴ならまだ許せます。
    > 凄い長い履歴だと何かあった時直すのも大変だし、
    > そもそも前任者(在職者なら救いはあるのですが)が何故このような履歴にしたのか理解する所から始めないといけないので好きじゃありません。

    何故か[履歴]を好む人が居るんですよね。
    確かに居ますねぇ〜。
    そういう人はプログラミングへの道へ進まない人ですけどね。(^^ゞ ※これは個人の感想です。

    >>[フォーム+イベント+表]による方法をだけをお勉強されることをお勧めします。
    >>・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    >>
    > はい。フォーム+イベント+表 を勉強していきます!

    以下の拙作webに最初の一歩の入門講座があります。

     桐のイベント処理の入門講座
    新 フォームアプリケーション入門 §1 http://silicon7565.html.xdomain.jp/primer/primer_section_01.html
    新 フォームアプリケーション入門 §2 http://silicon7565.html.xdomain.jp/primer/primer_section_02.html

    お時間がある時に実習してみてください。

    なお、この講座ではフォームの編集対象表がない NULLフォーム を使いますが、
    実はイベントのお勉強には NULLフォーム の方が適しているんですよ。


[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13871 ] / ▼[ 13873 ]
■13872 / 17階層)  Re[17]: 更新を判定出来ますか?
□投稿者/ 困り犬 -(2023/07/13(Thu) 16:43:10)
    No13871に返信(ONnojiさんの記事)

    > >>なお、現行では[製品長]と[製品幅]が書き換えられた時に[更新日]を変更していますが、
    > >>その際に、メッセージを表示することも可能です。
    > >>
    > >>例えば、
    > >>
    > >> [製品長]が変更されました
    > >> 変更前:900
    > >> 変更後:901
    > >>
    > >> データを保存してよろしいですか?
    > >> [はい] [いいえ]
    > >>
    > >>という具合です。
    >
    > 本当は項目訂正するつもりは無かったのに、うっかり項目訂正の場合にメッセージボックスを表示するものを作ってみましょうか?
    >
    > いかがでしょうか??
    >
    > ご返信ください。
    >
    はい。お言葉に甘え是非作って頂きたいです。

    >>今の自分の理解では、要領書の項目が多く この時はこのフォーム この時はこのフォーム と3種類位入力専用フォームを作って対応しようと思っていました。
    >>しかし、オートフォームでは 表示条件の登録 機能があるので、条件を登録したら1つのフォームだけを使用して入力が出来ると思いました。
    >
    > ↑このような使い方を考えていらっしゃる場合には、
    >
    >  要領書.wfx の[表示条件の読み込み][表示する項目を選択][表示条件の登録][表示条件の削除][許可作業]を復活させなければなりませんが、
    > その場合には、カスタマイズした内容の一部を変更する必要があります。
    >
    > 要領書.wfxでも、条件を使うようにしますか??
    >
    > これも併せてご返信ください
    >
    はい。こちらも併せて宜しくお願いします<m(__)m>

    >>現状の話をすると、私は履歴は嫌いなんです。
    >
    > 私も[履歴]は大大大大嫌いですよ。※これは個人の感想です。アハハha。
    > なので、[履歴]で作業をしたことがありませんよ。

    やっぱりそうですよね?
    私の周りには、私は履歴が好きじゃないと昔から公言していました。
    しかし、逆に言えば私を含め桐を扱うレベルが高く無いので、仕方なく履歴を使っているというのも事実なのです。

    こんなに桐って素敵なソフトなのに、認知度が低い為か何かあった時調べようと思っても情報が少ないので、知っている人からすると無茶な方法で解決するケースが多いです。

    >>ちょっとした履歴ならまだ許せます。
    >>凄い長い履歴だと何かあった時直すのも大変だし、
    >>そもそも前任者(在職者なら救いはあるのですが)が何故このような履歴にしたのか理解する所から始めないといけないので好きじゃありません。
    >
    > 何故か[履歴]を好む人が居るんですよね。
    > 確かに居ますねぇ〜。
    > そういう人はプログラミングへの道へ進まない人ですけどね。(^^ゞ ※これは個人の感想です。
    >
    > >>[フォーム+イベント+表]による方法をだけをお勉強されることをお勧めします。
    > >>・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    > >>
    >>はい。フォーム+イベント+表 を勉強していきます!
    >
    > 以下の拙作webに最初の一歩の入門講座があります。
    >
    >  桐のイベント処理の入門講座
    > 新 フォームアプリケーション入門 §1 http://silicon7565.html.xdomain.jp/primer/primer_section_01.html
    > 新 フォームアプリケーション入門 §2 http://silicon7565.html.xdomain.jp/primer/primer_section_02.html
    >
    > お時間がある時に実習してみてください。
    >
    > なお、この講座ではフォームの編集対象表がない NULLフォーム を使いますが、
    > 実はイベントのお勉強には NULLフォーム の方が適しているんですよ。
    >
    情報有難うございます!
    少し拝見させて頂きました。
    ここまで事細かく丁寧に記載された教材は初めて見ました。
    勉強させて頂きます<m(__)m>
[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13872 ] / ▼[ 13874 ]
■13873 / 18階層)  Re[18]: 更新を判定出来ますか?
□投稿者/ ONnoji -(2023/07/14(Fri) 11:44:17)
    2023/07/14(Fri) 18:43:58 編集(投稿者)
    2023/07/14(Fri) 12:33:12 編集(投稿者)

    要領書.wfx と 要領書.kex を鋭意製作中です。

    今日中にはアップ出来ると思います。

    添付画像を参考にしてください。

    なお、画像の上の方にある正方形の大きめのボタンを追加しました。

    このボタンは、[行訂正モード]を許可するボタンです。
    フォームが開いた直後は、このボタンは凸で行訂正/項目訂正が出来ないようにしています。
    オペレータはこのボタンを実行して凹ませるてから[行訂正/項目訂正]をしてください。

    なお、行追加・行挿入の場合にはこのボタンを押す必要はありません。

    p.s.

    データにもよりますが、一般的にはデータの書き換えの頻度はそれほど多くないですね。
    なので、通常は行訂正/項目訂正を禁止しておいて、必要に応じて許可するのが便利です。
    そうすることによって、うっかり操作でデータを書き換えてしまう事故は極端に減ると思います。

    また、オペレータさんにも操作のフィードバックが意識されるので、望ましいメンタルモデルが構築されると思います。(^^ゞ

[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13873 ] / ▼[ 13875 ]
■13874 / 19階層)  Re[19]: 更新を判定出来ますか?
□投稿者/ 困り犬 -(2023/07/14(Fri) 16:45:16)
    No13873に返信(ONnojiさんの記事)
    > 2023/07/14(Fri) 12:33:12 編集(投稿者)
    >
    > 要領書.wfx と 要領書.kex を鋭意製作中です。
    >
    > 今日中にはアップ出来ると思います。
    >
    > 添付画像を画像を参考にしてください。

    ありがとうございます!
    フォーム+イベント+表でこんなことまで出来るんですね!

    今日はほぼ社外でしたので、ご連絡遅くなり申し訳ありませんでした<m(__)m>

    宜しくお願いします。
[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13874 ] / ▼[ 13877 ]
■13875 / 20階層)  Re[20]: 更新を判定出来ますか?
□投稿者/ ONnoji -(2023/07/14(Fri) 17:21:40)
    2023/07/14(Fri) 17:50:54 編集(投稿者)

    > フォーム+イベント+表でこんなことまで出来るんですね!

    DOS桐の時代には一括処理でしたが、
    桐ver.8以降の時代には[フォーム+イベント処理+表]でアプリケーションを作るようになりましたよ。

    > 今日はほぼ社外でしたので、ご連絡遅くなり申し訳ありませんでした<m(__)m>

    いえいえお気にされる必要はありませんよ。

    あらかた出来上がっているのですが、最後の詰めで遠回りをしてしまいました。アハハha

    もうすぐ完成すると思います。

    <ボタンの説明>

    [訂正を許可する]ボタン
    このボタンが凹んでいる(または”ひまわり色”)の時にデータを[訂正]出来ます
    <重要>
    必要が無くなったら、もう一度ボタンを押して元に戻してください
    ※このボタンとは無関係に[行追加]と[行挿入]は常に可能です

    p.s.


    [訂正を許可する]ボタンは、オートフォームの[許可作業]ボタンで訂正をオン/オフするのと同じです。
    しかし、オートフォームの[許可作業]ボタンでは、ダイアログボックスを開かない限り、オペレータさんが現在の許可状態を把握できないために、
    [訂正を許可する]ボタンを用意した次第です。
    というわけで要領書.wfxの[許可作業]ボタンは非表示にしてあります。

[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13875 ] / ▼[ 13878 ]
■13877 / 21階層)  Re[21]: 更新を判定出来ますか?
□投稿者/ ONnoji -(2023/07/14(Fri) 18:16:46)
    2023/07/15(Sat) 09:18:07 編集(投稿者)
    2023/07/14(Fri) 18:17:38 編集(投稿者)

    カスタマイズが完成しました。

    添付ファイルを解凍すると、次の2つのファイルがあります。

     要領書.wfx
     要領書.kex

    フォームの編集対象表は 要領書.tbx に設定してありますので、
    この2つのファイルを、 要領書.tbx が存在するフォルダに解凍してください。

    なお、解凍はファイルは旧ファイルに上書きでも、旧ファイルを削除してからでもOKです。
    ※旧ファイルは不要だからきれいサッパリ消しちゃった方がいいかと思いますよ。

    当方で十分テストした(つもり)ですので、問題なく動くと思いますが、貴殿に動作の確認をお願いします。

    もしも、具合が悪い事があればお早めにご連絡ください。

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


[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13877 ] / ▼[ 13879 ]
■13878 / 22階層)  Re[22]: 更新を判定出来ますか?
□投稿者/ 困り犬 -(2023/07/15(Sat) 09:06:30)
    No13877に返信(ONnojiさんの記事)
    > 2023/07/14(Fri) 18:17:38 編集(投稿者)
    >
    >
    > カスタマイズが完成しました。
    >
    > 添付ファイルを解凍すると、次の2つのファイルがあります。
    >
    >  要領書.wfx
    >  要領書.kex
    >
    > フォームの編集対象表は 要領書.tbx に設定してありますので、
    > この2つのファイルを、 要領書.tbx が存在するフォルダに解凍してください。
    >
    早速、ご対応ありがとうございました!

    > 当方で十分テストした(つもり)ですので、問題なく動くと思いますが、貴殿に動作の確認をお願いします。
    >
    > もしも、具合が悪い事があればお早めにご連絡ください。

    はい。本日確認し報告します!
[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13878 ] / ▼[ 13880 ]
■13879 / 23階層)  Re[23]: 更新を判定出来ますか?
□投稿者/ ONnoji -(2023/07/15(Sat) 09:17:33)
    2023/07/15(Sat) 09:30:56 編集(投稿者)

    >>当方で十分テストした(つもり)ですので、問題なく動くと思いますが、貴殿に動作の確認をお願いします。
    >>
    >>もしも、具合が悪い事があればお早めにご連絡ください。
    >
    > はい。本日確認し報告します!

    休日出勤ですか?

    無理をしないでください。

    結果報告は急がなくて結構ですよ。

    時間が経てば気になる所が見つかるものですよ。

    なによりも、オペレータさんに実際に見てもらった評価を大事にしてください。
    といっても、出来ることと出来ないことがあるのも事実ですが・・・(^^ゞ

    p.s.

    ソフトウェアというのは凝りだしたらキリがありません。
    というわけで要領書.wfx/kexもまだまだの部分があると思います。

    一応、当方で気になっている点は次の2点です。

    ・[訂正を許可する]ボタンを実行した時に、メッセージボックスで[訂正]許可のガイダンスをする必要があるか?

     →オペレータさんは、表の操作は出来るのですから、今さらF2キーで訂正モード、スペースキーで項目訂正モードなどと
      ガイダンスする必要はないと思います。
      しかし、桐の操作に慣れていない人、またはオペレータとしての適性に欠けている人の場合には必要かなとも・・・

      私が危惧する事は、オペレータがこのボタンの機能を頭の中でイメージ出来ないことです。
               ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
      その場合には、しつこくなりますがメッセージボックスが必要になります。
      オペレータとしての適性があるひとならば問題ないでしょう。
      しかし、適性を欠く人にオペレーションを任せる場合には、出来る限りの処置が必要です。
      もしも、出来る限りの処置をしても、適性を欠く人の場合にはオペレーションのミスはまったく減らないものですよ。
      人間には向き不向きがあるので、これは仕方ありません。(^^ゞ

    ・[更新日]は手動で書き換え可能です。

     →[更新日]を書き換えたりしませんよね。と楽観的人考えておきましょうか?
      もちろん、ご要望があればお応え出来ます。

    と、本当に桐なのにキリがないのです。

    なお、、本件が解決済みになった場合でも、当方または他の人が投稿している場合もありますので、時々掲示板を見に来てください。

      
    p.p.s.

    余談ですが、[更新日]があるのならば、[登録日]つまり最初に登録した日があってもいいのではないかと存じますが、
    これも挿入初期値式で設定可能です。
    しかし、項目数がさらに1つ増えますし、[登録日]に価値を見出せない場合にはこの項目は無くても差し支えないですね。

[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13879 ] / ▼[ 13881 ]
■13880 / 24階層)  Re[24]: 更新を判定出来ますか?
□投稿者/ 困り犬 -(2023/07/15(Sat) 10:41:06)
    No13879に返信(ONnojiさんの記事)
    >
    > 休日出勤ですか?
    >
    > 無理をしないでください。

    今日は出勤日なんですよ(*^-^*)
    お気遣いありがとうございます!

    > なによりも、オペレータさんに実際に見てもらった評価を大事にしてください。
    > といっても、出来ることと出来ないことがあるのも事実ですが・・・(^^ゞ

    オペレーターは必ず気に入ると思います!

    > ・[訂正を許可する]ボタンを実行した時に、メッセージボックスで[訂正]許可のガイダンスをする必要があるか?

    作っておいて貰って言うのも何なんですが、[訂正を許可する]ボタンがあるように思いません。(このボタンは見せてもらった画像のオレンジ色のボタンですよね?)
    >
    >  →オペレータさんは、表の操作は出来るのですから、今さらF2キーで訂正モード、スペースキーで項目訂正モードなどと
    >   ガイダンスする必要はないと思います。
    >   しかし、桐の操作に慣れていない人、またはオペレータとしての適性に欠けている人の場合には必要かなとも・・・
    >

    確かに今のオペレーターの実力であればガイダンスは必要ないと思いますが、将来的にどんな人が使うか分からないので結果的にガイダンスがあった方が良いと考えます。
    >
    > ・[更新日]は手動で書き換え可能です。
    >
    >  →[更新日]を書き換えたりしませんよね。と楽観的人考えておきましょうか?

    更新日を手動で書き換えする事は全く想定していません。
    が、確かに更新日を書き換える人はいるかも知れませんね(@_@;)
    逆手にとって書き換える事はあるかもしれません!

    > なお、、本件が解決済みになった場合でも、当方または他の人が投稿している場合もありますので、時々掲示板を見に来てください。

    はい!見にきます!
    この掲示板自体は定期的に参考に出来そうな事がないかな? と見にきていたんですよ。
      
    > p.p.s.
    >
    > 余談ですが、[更新日]があるのならば、[登録日]つまり最初に登録した日があってもいいのではないかと存じますが、

    基本的にほとんどのケースで[更新日]=[登録日]なのです。
    本来この項目は必要ないのですが、ごく稀に仕様変更で寸法変更があるのです。

    会社に残す資料として、区分で絞り込んでレポートで印刷すれば[更新日]が当日の時(実際には、新規登録をした か 従来品更新をした日)色を変えて印刷する様にしたかったのです。

    元々の話をすれば、要領書は複数のエクセル、シートで管理していました。
    そうすると、管理が煩雑になるし、全く同じ物なのに違う寸法で入力していたりと細かいミスがありました。(この細かいミスは桐にデータを移行して発覚したのですが・・・)

    良くも悪くも、エクセルは簡単なのでどんなオペレーターでも一定の事が出来るし困った事があればインターネットで調べれば参考事例が沢山出てきます。

    しかし、管理する行数・項目数が多い為、桐でデータベース化した方が管理しやすいと思い(今のオペレーターの実力も高いので)一念発起して桐へデータを移行しました。

    エクセルの時は、新規登録 若しくは 更新 をした行を色を付けて印刷していました。
    その方法自体は分かりやすいので上記の通り色付きで印刷し資料とする為に作った項目なのです。

    p.s.

    今回のフォームですが、しびれました。
    どの項目を更新しても更新日が変更されますし、誤って項目訂正で更新すればガイダンスが出てくるので、言語化できないがこうしたいなと言うイメージが、具現化した感じです。

    正にこんなイメージの物が欲しかったです。
    今回は本当にありがとうございました!

[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13880 ] / ▼[ 13882 ]
■13881 / 25階層)  Re[25]: 更新を判定出来ますか?
□投稿者/ ONnoji -(2023/07/15(Sat) 11:17:57)
    >>なによりも、オペレータさんに実際に見てもらった評価を大事にしてください。
    >>といっても、出来ることと出来ないことがあるのも事実ですが・・・(^^ゞ
    >
    > オペレーターは必ず気に入ると思います!
    >
    >>・[訂正を許可する]ボタンを実行した時に、メッセージボックスで[訂正]許可のガイダンスをする必要があるか?
    >
    > 作っておいて貰って言うのも何なんですが、[訂正を許可する]ボタンがあるように思いません。(このボタンは見せてもらった画像のオレンジ色のボタンですよね?)
    >
    > 確かに今のオペレーターの実力であればガイダンスは必要ないと思いますが、将来的にどんな人が使うか分からないので結果的にガイダンスがあった方が良いと考えます。

    [訂正を許可する]ボタンはトグルで操作します。
    つまり、ボタンを押して凹んでいる(または、ひまわり色の)時に行訂正・項目訂正が許可されています。
    もう一度ボタンを押すと、立体(凸)またはフォーム同じ色になって、行訂正・項目訂正が禁止されます。
    [訂正を許可する]ボタンにマウスポインタを当てると、ツールヒント(いわゆる吹き出し)でガイドされます。
    ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    なお、拙作のコマンドボタンの多くには、ツールヒント(いわゆる吹き出し)がセットされています。
    ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    これは是非覚えておいてください。

    > しかし、管理する行数・項目数が多い為、桐でデータベース化した方が管理しやすいと思い(今のオペレーターの実力も高いので)一念発起して桐へデータを移行しました。
    >
    > エクセルの時は、新規登録 若しくは 更新 をした行を色を付けて印刷していました。
    > その方法自体は分かりやすいので上記の通り色付きで印刷し資料とする為に作った項目なのです。

    印刷のためですか?、なるほどですね。

    > 今回のフォームですが、しびれました。
    > どの項目を更新しても更新日が変更されますし、誤って項目訂正で更新すればガイダンスが出てくるので、
    > 言語化できないがこうしたいなと言うイメージが、具現化した感じです。
    > 正にこんなイメージの物が欲しかったです。

    桐の[フォーム+イベント処理+表]は、エクセルよりも簡単ですよ。

    それでも、イチから作るのは大変です。
    なので、拙作フレームワークのように、あらかじめ基本機能が組み込まれて完成しているフォームが必要なのです。

    フレームワークを利用したフォームがあれば、

    ・桐のアプリケーションを使うだけの人
    ・自分でアプリケーションを作って使う人
    ・アプリケーションの開発を専門にする人

    これらすべての人の作業が楽になるという次第ですよ。


    p.s.

    > 確かに今のオペレーターの実力であればガイダンスは必要ないと思いますが、
    > 将来的にどんな人が使うか分からないので結果的にガイダンスがあった方が良いと考えます。

    了解です。

    追ってイベント処理:要領書.kexをアップします。


[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13881 ] / ▼[ 13884 ]
■13882 / 26階層)  Re[26]: 更新を判定出来ますか?
□投稿者/ 困り犬 -(2023/07/15(Sat) 11:54:26)
    No13881に返信(ONnojiさんの記事)
    >>作っておいて貰って言うのも何なんですが、[訂正を許可する]ボタンがあるように思いません。(このボタンは見せてもらった画像のオレンジ色のボタンですよね?)
    >>
    > [訂正を許可する]ボタンはトグルで操作します。
    > つまり、ボタンを押して凹んでいる(または、ひまわり色の)時に行訂正・項目訂正が許可されています。
    > もう一度ボタンを押すと、立体(凸)またはフォーム同じ色になって、行訂正・項目訂正が禁止されます。
    > [訂正を許可する]ボタンにマウスポインタを当てると、ツールヒント(いわゆる吹き出し)でガイドされます。
    >
    すみません。
    私のミスでした。
    ちゃんとボタン有りました。
    (バックアップの関係で、フォームの確認をするのにバックアップファイルでテストしていましたが、オリジナルファイルから昨日までのファイルが上書きされていました。)

    ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    > なお、拙作のコマンドボタンの多くには、ツールヒント(いわゆる吹き出し)がセットされています。
    > ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    この吹き出しがかなり助かっています。
    本当に親切設計だと実感しております。

    > p.s.
    >
    >>確かに今のオペレーターの実力であればガイダンスは必要ないと思いますが、
    >>将来的にどんな人が使うか分からないので結果的にガイダンスがあった方が良いと考えます。
    >
    > 了解です。
    >
    > 追ってイベント処理:要領書.kexをアップします。
    >

    有難うございます!

    p.s.

    現状の感想ですが、[訂正を許可する]ボタンはかなり便利です。
    なぜなら、[許可作業...]ボタンは自分で許可を選択(本来はこちらの方が良いと思います)しますが、[訂正を許可する]ボタンはボタン一つで、編集自体出来ない、出来るが 可能ですし、見た目にも オン・オフ が分かります。

    ONnojiさんの作業者目線は凄いと思います。
    痒い所に手が届いています。

    各ボタンにはツールヒントがありますし、吹き出しを見ればボタンの意味が分かります。

    これも「ハリウッドの原則」ですよね?
    本当に親切設計だと感心しております<m(__)m>
[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13882 ] / ▼[ 13885 ]
■13884 / 27階層)  Re[27]: 更新を判定出来ますか?
□投稿者/ ONnoji -(2023/07/15(Sat) 12:11:35)
    2023/07/15(Sat) 12:15:11 編集(投稿者)

    >>確かに今のオペレーターの実力であればガイダンスは必要ないと思いますが、
    >>将来的にどんな人が使うか分からないので結果的にガイダンスがあった方が良いと考えます。
    >
    > 了解です。
    >
    > 追ってイベント処理:要領書.kexをアップします。

    メッセージボックスを表示するように改修しました。

    ご自身でメッセージの文言を変更したい場合には、
    プロシージャ(一般手続き)の cmd訂正を許可するClick( )の変数:&msg を変更してください。

    こちら
     ↓
    手続き定義開始 cmd訂正を許可するClick( 整数 &editingAllow )
     変数宣言 自動,文字列{ &icon, &title = "cmd訂正を許可するClick( )", &msg }
     トレース出力 &title + " 引数:&editingAllow = " + #str( &editingAllow )

     変数宣言 自動,文字列{ &formObjectName = #半角( "フォーム" ) }
     条件 ( #変数( "INFmKnjForm" ) ) &formObjectName = #全角( &formObjectName )

     if ( &editingAllow )
      オブジェクト操作 &formObjectName{ 行訂正 = 1 }

      &msg =      "[訂正を許可する]ボタンが【オン(ON)】になりました"
      &msg = &msg +  "\n" + #複写( "-", 72 )
      &msg = &msg +  "\n[訂正を許可する]ボタンが押されました"
      &msg = &msg +  "\n[F2]キー  で訂正できます"
      &msg = &msg +  "\n[スペース]キーで項目訂正できます"
      &msg = &msg + "\n\nボタンが凹んでいる(または"”ひまわり色"”)の時にデータを[訂正]出来ます"
      &msg = &msg +  "\n<重要>\n必要が無くなったら、もう一度ボタンを押して元に戻してください"
      &msg = &msg +  "\n※このボタンとは無関係に[行追加]と[行挿入]は常に可能です"
     else
      オブジェクト操作 &formObjectName{ 行訂正 = 0 }

      &msg =      "[訂正を許可する]ボタンが【オフ(OFF)】になりました"
      &msg = &msg +  "\n" + #複写( "-", 72 )
      &msg = &msg +  "\n[訂正を許可する]ボタンが押されました"
      &msg = &msg +  "\n[F2]キーと[スペース]キーを使ったデータの訂正操作を禁止しました"
      &msg = &msg + "\n\nボタンが凹んでいる(または"”ひまわり色"”)の時にデータを[訂正]出来ます"
      &msg = &msg +  "\n※このボタンとは無関係に[行追加]と[行挿入]は常に可能です"
     end

     &icon = "i"
     手続き実行 INFprcMsgPause( &icon, &title, &msg )

    手続き定義終了

    p.s.

    > すみません。
    > 私のミスでした。
    > ちゃんとボタン有りました。

    こういう事が起こりますので、古いファイルはディスクから削除してください。



[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13884 ] / 返信無し
■13885 / 28階層)  Re[28]: 更新を判定出来ますか?
□投稿者/ 困り犬 -(2023/07/15(Sat) 13:37:14)
    No13884に返信(ONnojiさんの記事)

    > メッセージボックスを表示するように改修しました。

    早速の対応ありがとうございます。
    体感として、こちらの方が分かりやすいと思います。
    オペレーターにも火曜日に感想を聞いてみます。

    > ご自身でメッセージの文言を変更したい場合には、
    > プロシージャ(一般手続き)の cmd訂正を許可するClick( )の変数:&msg を変更してください。
    >
    > こちら
    >  ↓
    > 手続き定義開始 cmd訂正を許可するClick( 整数 &editingAllow )
    >  変数宣言 自動,文字列{ &icon, &title = "cmd訂正を許可するClick( )", &msg }
    >  トレース出力 &title + " 引数:&editingAllow = " + #str( &editingAllow )
    >
    >  変数宣言 自動,文字列{ &formObjectName = #半角( "フォーム" ) }
    >  条件 ( #変数( "INFmKnjForm" ) ) &formObjectName = #全角( &formObjectName )
    >
    >  if ( &editingAllow )
    >   オブジェクト操作 &formObjectName{ 行訂正 = 1 }
    >
    >   &msg =      "[訂正を許可する]ボタンが【オン(ON)】になりました"
    >   &msg = &msg +  "\n" + #複写( "-", 72 )
    >   &msg = &msg +  "\n[訂正を許可する]ボタンが押されました"
    >   &msg = &msg +  "\n[F2]キー  で訂正できます"
    >   &msg = &msg +  "\n[スペース]キーで項目訂正できます"
    >   &msg = &msg + "\n\nボタンが凹んでいる(または"”ひまわり色"”)の時にデータを[訂正]出来ます"
    >   &msg = &msg +  "\n<重要>\n必要が無くなったら、もう一度ボタンを押して元に戻してください"
    >   &msg = &msg +  "\n※このボタンとは無関係に[行追加]と[行挿入]は常に可能です"
    >  else
    >   オブジェクト操作 &formObjectName{ 行訂正 = 0 }
    >
    >   &msg =      "[訂正を許可する]ボタンが【オフ(OFF)】になりました"
    >   &msg = &msg +  "\n" + #複写( "-", 72 )
    >   &msg = &msg +  "\n[訂正を許可する]ボタンが押されました"
    >   &msg = &msg +  "\n[F2]キーと[スペース]キーを使ったデータの訂正操作を禁止しました"
    >   &msg = &msg + "\n\nボタンが凹んでいる(または"”ひまわり色"”)の時にデータを[訂正]出来ます"
    >   &msg = &msg +  "\n※このボタンとは無関係に[行追加]と[行挿入]は常に可能です"
    >  end
    >
    >  &icon = "i"
    >  手続き実行 INFprcMsgPause( &icon, &title, &msg )
    >
    > 手続き定義終了

    解説ありがとうございます。
    もし、文言を変更したい事があればここを変更し対応します。

    > p.s.
    >
    >>すみません。
    >>私のミスでした。
    >>ちゃんとボタン有りました。
    >
    > こういう事が起こりますので、古いファイルはディスクから削除してください。
    >
    はい。今後その様に対応します。
    アドバイスありがとうございます。

    p.s.

    今、三角形の面積を求めるを実際に作っています。
    今回の件が無ければ[フォーム+イベント処理+表]の事を勉強しようと思いませんでした。

    もっと桐の事を勉強して本当の意味で使いやすい[フォーム+イベント処理+表]を自分でも作れるように精進していきます!

    本当に有難うございました!
[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13855 ] / ▼[ 13861 ]
■13858 / 3階層)  Re[3]: 更新を判定出来ますか?
□投稿者/ 尾形 -(2023/07/11(Tue) 11:01:45)
    どうも、こんにちは


    入力前の表を確保しておいて

    併合コマンドとかで
    [製品長] と [製品幅]で照合して
    [更新日] 書き込みするとか


    あくまで一例としてです


[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 13858 ] / 返信無し
■13861 / 4階層)  Re[4]: 更新を判定出来ますか?
□投稿者/ 困り犬 -(2023/07/11(Tue) 14:04:02)
    No13858に返信(尾形さんの記事)
    > どうも、こんにちは
    >
    >
    > 入力前の表を確保しておいて
    >
    > 併合コマンドとかで
    > [製品長] と [製品幅]で照合して
    > [更新日] 書き込みするとか
    >
    確かに元表と比較して差異を判定する方法もありますね!
    コメントありがとうございます。
[ 親 13853 / □ Tree ] 返信 [メール受信/OFF] 削除キー/


Mode/  Pass/

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

- Child Tree -
- Antispam Version -