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

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

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

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

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

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

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

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

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

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


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

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

    今回は本当にありがとうございました！
解決済み!
引用返信 [メール受信/OFF] 削除キー/
■13864 / ResNo.11) 　Re[9]: 更新を判定出来ますか？
□投稿者/ ONnoji -(2023/07/12(Wed) 10:15:11)
    2023/07/12(Wed) 10:35:28 編集(投稿者)

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

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

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

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

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

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

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

    了解です。(^^)v

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

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

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

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

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

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

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

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

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

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

    ｐ．ｓ．

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

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

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

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

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


引用返信 [メール受信/OFF] 削除キー/
■13865 / ResNo.12) 　Re[10]: 更新を判定出来ますか？
□投稿者/ ONnoji -(2023/07/12(Wed) 15:24:22)
    > 項目　製品長(数値)　と　項目　製品幅(数値)　の情報を更新した時のみ
    > 更新日(日時)　を今日の日付に変更する事は可能でしょうか？

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

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

    ＜手続き一覧＞

    名札　メイン

    cmdStartupClick

    txtField_24::入力前

    txtField_24::入力後
    │
    └ prc項目値代入実行

    ■名札 メイン

    　　変数宣言　局所，文字列｛ &mString ｝

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


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

    　txtField_1::入力前/txtField_1::入力後　〜　txtField_100::入力前/txtField_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 )
    　繰り返し終了

    手続き定義終了


引用返信 [メール受信/OFF] 削除キー/
■13866 / ResNo.13) 　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 ｝
    >
    > 　局所変数を１つ宣言しています。
    >
    >
    > ■入力前と入力後のイベントハンドラ
    >
    > 　txtField_1::入力前/txtField_1::入力後　〜　txtField_100::入力前/txtField_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 )

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

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

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



引用返信 [メール受信/OFF] 削除キー/
■13867 / ResNo.14) 　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行めでに記述した［手続き定義開始...手続き定義終了］です。
    合計２００個あります。
    実は手で書いたわけでもコピペしたわけでもなく、プログラムを組んで作成したテキストを読み込んだものです。
    こういった単純な繰り返しは手操作で行うと必ずミスをするものなので・・・(^^ゞ

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

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

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

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

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

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

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

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

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

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

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

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

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


    ｐ．ｓ．

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

    ハイ！、ご明察です。

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

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

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

    　INF_Framework.cmx
    　IPS_Framework.cmx

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

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

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

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

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

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

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

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

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

    　　■ハリウッドの原則
    　　　フレームワークの性質を端的に表す良く知られた言葉として、ハリウッドの原則(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.　＞　ＡＬＬ

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


引用返信 [メール受信/OFF] 削除キー/
■13868 / ResNo.15) 　Re[13]: 更新を判定出来ますか？
□投稿者/ 困り犬 -(2023/07/13(Thu) 08:56:18)
    ■No13867に返信(ONnojiさんの記事)

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

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

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

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

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

    >
    > ｐ．ｓ．
    >
    >>FW_オートINF_Framework_MkII.kex　と　要領書.kex　の　差異を見ていました。
    >>
    >>・要領書.kexには　2行目に　変数宣言　局所，文字列｛ &mString ｝がある
    >>
    >>・要領書.kexには　252行目　から　1296行目が追加してある（ここがカスタムして頂いた所ですよね？ありがたいです！）
    >
    > ハイ！、ご明察です。
    >
    > ところで、FW_オートINF_Framework_MkII.kex の内容を見て気が付かれたと思いますが、
    > たったの 253行で、しかも［名札　メイン］の部分しかありません。
    >
    > これって不思議に思われたかもしれませんね。

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

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

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

    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さんのホームページや、桐のヘルプにある一括処理･履歴･イベントを教材にして知識を深めていこうと思います！
引用返信 [メール受信/OFF] 削除キー/
■13869 / ResNo.16) 　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 = "[項目名]" ) という要領です。
    >>
    >>今後はこれで貴殿の自力で改修できるハズですよ。
    >
    > 何から何まで教えて下さりありがとうございます！
    > その部分を追加する事なら私でも対応できそうです。
    > 本当にありがとうございます。
    >
    >>
    >>なお、あまりにも項目名の数が多くなった場合には、別の書き方があるのでその際にお問い合わせください。
    >>
    > はい。お言葉に甘えて問い合わせさせて貰います。

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

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

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

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

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

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

    例えば、

    　[製品長]が変更されました
    　変更前：９００
    　変更後：９０１

    　データを保存してよろしいですか？
    　［はい］　［いいえ］

    という具合です。

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

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

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

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

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

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

    > 最初　要領書の入ったファイルに
    >
    > 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さんのホームページや、桐のヘルプにある一括処理･履歴･イベントを教材にして知識を深めていこうと思います！

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

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

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

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

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




引用返信 [メール受信/OFF] 削除キー/
■13870 / ResNo.17) 　Re[15]: 更新を判定出来ますか？
□投稿者/ 困り犬 -(2023/07/13(Thu) 11:31:20)
    ■No13869に返信(ONnojiさんの記事)
    > 2023/07/13(Thu) 10:36:43 編集(投稿者)

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

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

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

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

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

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


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

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

    > ［フォーム＋イベント＋表］による方法をだけをお勉強されることをお勧めします。
    > ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    >
    はい。フォーム＋イベント＋表　を勉強していきます！
引用返信 [メール受信/OFF] 削除キー/
■13871 / ResNo.18) 　Re[16]: 更新を判定出来ますか？
□投稿者/ ONnoji -(2023/07/13(Thu) 14:27:16)
    2023/07/13(Thu) 14:47:44 編集(投稿者)

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

    なるほどですね。

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

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

    いかがでしょうか？？

    ご返信ください。

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

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

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

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

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


    ｐ．ｓ．

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

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

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


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

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

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

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

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

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

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

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

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


引用返信 [メール受信/OFF] 削除キー/
■13872 / ResNo.19) 　Re[17]: 更新を判定出来ますか？
□投稿者/ 困り犬 -(2023/07/13(Thu) 16:43:10)
    ■No13871に返信(ONnojiさんの記事)

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

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

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

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

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

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

スレッド内ページ移動 / << 0 | 1 | 2 | 3 >>

このスレッドに書きこむ
Mode/　 Pass/

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

- Child Tree -
- Antispam Version -