■13867 / ) |
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
↑のように、拙作フレームワークには「ハリウッドの原則」が適用されるのだとご理解いただければ幸いです。(^^ゞ
|
|