■記事リスト / ▼下のスレッド
/ ▲上のスレッド
| ■512 / 親記事) |
モードレスB で さよなら。モードレスB を閉じる
|
□投稿者/ ONnoji -(2024/09/18(Wed) 20:45:45)
| 2024/09/19(Thu) 07:41:50 編集(投稿者)
ジェダイの桐さん
> スレッドを興味深く読ませて頂いています。
> こちらの解説を読むことで、出来るかどうかは別として
> >ウィンドウ終了コマンドでフォームを閉じる事は、有りなのかが知りたい。
> この考え方は、「 フォーム + イベント 」 では不自然だと言う事が、より理解出来ました(^^ゞ
考え方でありますが・・・
以前、こういうのがありましたね。(^^ゞ
■491 / 9階層) Thin_INF_Framework のご案内
□投稿者/ ONnoji -(2024/09/10(Tue) 18:33:52)
>> 最終的には モードレスな「フォーム＋イベント処理」＋モードレスな「フォーム＋イベント処理」 を目指したいですが、
>> モードレスA → こんにちは。モードレスB → モードレスB で こんにちは。モードレスB を表示
>> モードレスB → こんにちは。モードレスA → モードレスA で こんにちは。モードレスA を表示
>> と言う、やり取りを作る所からというイメージを抱きました。
この視点からすると・・・、
モードレスA → さよなら。モードレスB → モードレスB で さよなら。モードレスB を閉じる
モードレスB → さよなら。モードレスA → モードレスA で さよなら。モードレスA を閉じる
になりますよね。(^^ok
どうも混乱されているようなので、頭の中を整理しましょう。(^^ゞ
結論からすると以下のようになります。
× ［ウィンドウ終了 <ハンドル>］
△ ［メソッド呼び出し ハンドル = <ハンドル>, 戻り値 = <変数名>, <コマンドボタン>.実行()］
※ただし、<コマンドボタン>には［機能名：閉じる］が設定してあるとします
〇 &sendMacro = "メソッド呼び出し ハンドル = <ハンドル>, 戻り値 = <変数名>, <コマンドボタン>.実行()"
手続き実行 HDLCOMprcMacroSend( &hdl, &sendMacro, &done )
理由を示して解説すると・・・
× は、まるでダメ男です。これは一括処理の中では有効ですが、［フォーム＋イベント処理］では百害あって一利なしです。
△ は、確かに実行できます。しかし、自分自身以外のフォームとの結合度が強くなります。フォームの場合でも強い結合度は好ましくありません。
ダイレクトにハンドルを指定してメソッドを実行するので、自分自身以外のフォームとの結合度が強くなります。
プログラムの流れは、複数のフォームのイベントハンドラや手続きを誘発しながら、
・・・・・・・・・・・・・・・・・・・・・・・・・・・
連続して発生するのでプログラムの流れを追うこと困難になります。つまり、デバッグし難いアプローチです。
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
〇 は、INF_Frameworkの［HDLCOM］機能を利用しています。［HDLCOM］機能は相手のフォームの［タイマー］を経由して実行するので、
自分自身以外のフォームとの結合度が弱くなります。
・・・・・・・・・・・・・・・・・・・・・・・
プログラムの流れは自身のフォームのプログラムの流れが終わってから、
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
フォーム毎に別々に発生するので、プログラムの流れを追うこと簡単です。つまり、デバッグし易いアプローチです。
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
以上のような結果に、「なりマンネン。なるんデッセ。なるチューテンネン。なりまんニャワ」。v(^^)v
ｐ．ｓ．
以前、こんなやりとりがありましたっけ。(^^ゞ
■501 Re[3]: Thin_INF_Framework のご案内
□投稿者/ ジェダイの桐 -(2024/09/12(Thu) 12:21:12)
> HDLCOMprcMacroSend について
> フォーム間で 値の送信が出来る素晴らしい仕組みです。
> 何故、フォーム間での 値送信 がやりたかったか思い出しました。
> 私の シックリくる こない の全てのスタート地点が
> ■14365 モジュール化はフォームのレベルでも必要
> なのです。
> 相手側で 主 に直接影響を与えるアプローチは良くない の概念がここで生まれたのでした(^^ゞ
> あの時は、プログラムを書くこと自体がほぼ初めてでした。
> 下手に固定概念が着く前に上記の概念を教えて頂いた事が私にとって物凄い幸運でした(^^♪
> それで 解決方法 &gAnswer を使ったアプローチサンプルをご提案頂きました。
> この時に "ピタゴラスイッチ" を覚えました。
> 同一の ○○.kex 内であれば 手続きで 値渡し 若しくは 戻り値でピタゴラスイッチが作れます。
> 複数のフォーム間であった時、 値渡し が出来れば 相手側に直接影響を与えず、
> ピタゴラスイッチ によって プログラム発動有無が決めれるのにな・・・
> という思いが 値送信 に固執したのです。
> 明らかに、幅が広がりますよね(^^♪
■502 Re[4]: Thin_INF_Framework のご案内
□投稿者/ ONnoji -(2024/09/12(Thu) 14:39:00)
> HDLCOMprcMacroSend は、&hdl で指定したフォームに桐で実行できるコマンドを送信する機能です。
> 従って、変数を代入する静的なものではなく、コマンドまたはメソッドを実行する動的なものです。
>
> 例えば、変数：&hdl で指定したフォームに［確認］コマンドを送るには次のようにします。
>
> 変数宣言 自動，文字列｛ &targetFileName ｝
> 変数宣言 自動，文字列｛ &sendMacro ｝
> 変数宣言 自動，整数 ｛ &found, &status, &multi, &mode ｝
> 変数宣言 自動，整数 ｛ &hdl, &done ｝
>
> &targetFileName = #一括パス名 + "hoge.wfx"
> 手続き実行 HDLLNCprcHdlSeek( &targetFileName, &found, &status, &multi, &mode )
>
> if ( &found .and &status ) /* フォームのウィンドウが見つかった */
>
> &sendMacro = "確認"
> &hdl = &found
> 手続き実行 HDLCOMprcMacroSend( &hdl, &sendMacro, &done )
> end
> HDLCOMprcMacroSend は、&hdl で指定したフォームに桐で実行できるコマンドを送信する機能です。
> ・・・・・・・・・・・・・・・・・・
> 従って、変数を代入する静的なものではなく、コマンドまたはメソッドを実行する動的なものです。
> 例えば、変数：&hdl で指定したフォームに［確認］コマンドを送るには次のようにします。
|
|
|
▽[全レス7件(ResNo.3-7 表示)]
| ■515 / ResNo.3) |
Re[2]: モードレスB で さよなら。モードレスB を閉じる
|
□投稿者/ ジェダイの桐 -(2024/09/19(Thu) 11:22:10)
| ONnojiさん
こんにちは！
提示頂いた、手続きで
> &targetFileName = #一括パス名 + "transaction_B.wfx"
→ &targetFileName = #一括パス名 + "sample_入荷トランザクション.wfx"
へ置き換えて、実際に cmdTest を押してみました。
結果、 sample_入荷トランザクション.wfx は閉じました。
サンプル提示ありがとうございましたm(__)m
ｐ.ｓ.
cmdTest を トレース出力ウィンドウ を出して実行しました。
初めて フォーム終了イベント を見ました。
使った事はないですが、 フォーム開始イベント で設定が出来る事は知っていました。
同様に フォームを閉じる時も 何か設定が出来るのですね(^^♪
|
|
|
| ■516 / ResNo.4) |
Re[3]: モードレスB で さよなら。モードレスB を閉じる
|
□投稿者/ ONnoji -(2024/09/19(Thu) 11:56:12)
| 2024/09/19(Thu) 12:06:26 編集(投稿者)
ジェダイの桐さん
>> &targetFileName = #一括パス名 + "transaction_B.wfx"
> → &targetFileName = #一括パス名 + "sample_入荷トランザクション.wfx"
> へ置き換えて、実際に cmdTest を押してみました。
> 結果、 sample_入荷トランザクション.wfx は閉じました。
シーカーで探索して見つかったハンドルのフォームに
実行したいコマンドボタンオブジェクトが存在するか否かを
メソッド呼び出し ハンドル = &hdl, @フォーム.オブジェクト検査( &objectName, &isObject )
で確かめた後に
&sendMacro = "メソッド呼び出し @cmd閉じる.実行()"
手続き実行 HDLCOMprcMacroSend( &hdl, &sendMacro, &done )
でセンダーを実行しています。
［オブジェクト検査］で石橋を叩いてから、橋が通行可能か調べています。
このように、確実な手順を踏む習慣をお勧めします。
> ｐ.ｓ.
> cmdTest を トレース出力ウィンドウ を出して実行しました。
> 初めて フォーム終了イベント を見ました。
> 使った事はないですが、 フォーム開始イベント で設定が出来る事は知っていました。
> 同様に フォームを閉じる時も 何か設定が出来るのですね(^^♪
Thin INF_Framework もオートINF_Framework と同じです。
↓以下は、FW_オートINF_Framework_MkII.kex の［名札 メイン］に書かれている注意です。
※ Thin INF_Framework のプロトタイプでは記述を省略してあります。
*---------- begin オートINF_Framework ノート ---------------*
** オートINF_Framework.wfm/.kev/.cmd IPS_form 第 5.4 版
** ＜ご注意＞
** １．以下のイベントハンドラは予約済みです。このイベント処理ファイル( .kev )に、これらのイベントハンドラを作らないで下さい。
** フォーム::フォーム開始
** フォーム::フォーム終了
** フォーム::レコード移動
** フォーム::キーダウンﾝ
** フォーム::システムキーダウン
** フォーム::タイマー1
** フォーム::タイマー2
** ２．項目名ラベル( lblCaption_1 ～ lblCaption_100 )オブジェクトは変更しないで下さい。
** ３．項目テキスト( txtField_1 ～ txtField_100 )オブジェクトは変更しないで下さい。
** ４．項目テキスト( txtField_1 ～ txtField_100 )オブジェクトのイベントハンドラは作成しないで下さい。
** ５．以下のファミリのベントハンドラは予約済みです。このイベント処理ファイル( .kev )に、これらのイベントハンドラを作らないで下さい。
** famCAP
** famEZW
** famFLD
** famRecordUpDown
** famSpinButton
** famModernUI
*---------- end オートINF_Framework ノート ---------------*
つまり、
［フォーム::フォーム開始］
［フォーム::フォーム終了］
［フォーム::レコード移動］
［フォーム::キーダウン］
［フォーム::システムキーダウン］
［フォーム::タイマー1］
［フォーム::タイマー2］
以上の７つのイベントは自作しないでください。
もしも、これらのイベントハンドラを、イベント処理(.kex)に作ってしまうと、INF_Framework が正しく動作しなくなります。
特に、［フォーム::フォーム開始］と［フォーム::フォーム終了］のイベントハンドラをイベント処理(.kex)に作ってしまうと、即座に INF_Famework が動作しなくなります。
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
だから、これらのの７つのイベントは自作しないでください。
ちなみに、これらの７つのイベントは初級者には使い道と使い方が難しいイベントです。また、虫も出やすい厄介な所なんですよ。(^^ゞ
ということで、INF_Framework を使用する人は、
［フォーム::フォーム開始］の代用として、［開始時実行コマンド］ボタン（例えば cmdStartup）を使ってください。
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
［フォーム::フォーム終了］の代用として、［終了時実行コマンド］ボタン（例えば cmdFinish ）を使ってください。
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
ｐ．ｓ．
どうしても［７つのイベント］のいずれかを使いたい場合には、もちろん対処方法はあります。
ただし、初従者や上級者のレベルの人にはおススメできませんので、特に公開はしていません。ご了承ください。
|
|
|
| ■517 / ResNo.5) |
Re[2]: モードレスB で さよなら。モードレスB を閉じる
|
□投稿者/ ONnoji -(2024/09/19(Thu) 13:09:12)
| 2024/09/19(Thu) 13:40:02 編集(投稿者)
ジェダイの桐さん
> トレース出力で ［HDLCOM］機能 を見ると、
> 手続きを実行したフォームの手続きが終わる → 相手フォームで when 手続き"ﾌｫｰﾑ::ﾀｲﾏｰ2( )"を実行開始しました が始まる
> という流れが読み取れます。
> これが
> ■14365 モジュール化はフォームのレベルでも必要 にある
>>「イベント駆動型」では、複数のフォームが存在しても、それらは独立していなければならないのです。
> や
> 目からウロコのデータベース桐プログラミング入門 の
> ７ モジュラー設計 にある
> 「ひとつのモジュールはひとつの機能を担当する」
> という事なのだと思いました(^^♪
以前、「データを中心に考えれば失敗しないが、しかし、プロセス（処理）中心に考えると失敗します。」という趣旨の事を書きました。
これは、［フォームのウィンドウ］も同じですよ。
脳の中が［プロセス（処理）中心］で考える人は、［フォームのウィンドウ］だってプロセス（処理）の対象なんですね。
だから、フォームのアッチコッチに余計なオブジェクトを貼り付けて、
さらに［フォームのウィンドウ］の連携も上から目線で高飛車に強引にやろうとするんですね。
でも、脳の中が［データ中心］で考える人は、独立したデータである表(.tbx)にフォームをラップ（包む）しただけのものに見えますよ。
そうすれば、［フォームのウィンドウ］の連携は緩やかなものになると思いますよ。
そう、すべての［フォームのウィンドウ］は、独立していて干渉し合わない。
もしも、［フォームのウィンドウ］と［フォームのウィンドウ］の間で何か行う場合には「メッセージを送ればいい」とね。
［データ中心］で考えていくと、こういう結論になると思うのですよ。
少なくとも私( ONnoji )はズ～ット昔からそう考えてきたワケです。アハハハha
ちなみに、手続きと手続きの関係も同じですよ。(^^ゞ
「出来るだけ引数を使って結合する」ようにします。でもね、全てにするのは大変なので出来るだけですけどね。
> 本当に掲示板で相談して良かったと思っていますm(__)m
私( ONnoji )は、ジェダイの桐さんが解決したい問題は、INF_Framework を使えば簡単に解決できることは最初から気が付いていました。
でも、何でも自前主義、つまり「車輪の再発明」にコダワル人だったらと心配していたのです。
そこで、Thin INF_Framework を恐る恐る提案させていただいたのです。
その結果は、快諾していただけて良かったです。(^^♪
こういう作品は実際に使う人が現れないとブラシアップ出来ないんですよ。
こちらこそ、ありがとうございます。m(__)m
Thin INF_Framework の正式リリースは、まだ当分先になると思います。
現在、桐ｓで［リボンを使う］場合に発生する虫の対策を検討中です。
ということで、まだまだ先になります。
ｐ．ｓ．
蛇足ですが・・・(^^ゞ
INF_Framework 第2.1版 の readme.txt の内容
----------------------------------------------------------------
INF Tools Framework 第2.1版 for 桐ver.8 / 桐ver.9 / 桐ver.9-200X
INF Tools Framework Rev.72：オリジナル
By ONnoji Copyright (C) 2003-2008
【URL】ｈttp://www.geocities.jp/siliconvalley_bay_7565/
----------------------------------------------------------------
■ソフトの種類
対象：桐のアプリケーション開発者
種類：フォーム( .wfm )、イベント処理( .kev )、ライブラリ( .cmd )によるフレームワーク
■ソフトの内容
・一覧表形式や伝票形式のフォームが、表編集のように左右スクロールします。
・一覧表形式や伝票形式のフォームが、表編集のように列固定出来ます。
・フォームのオブジェクトの幅をマウスドラッグで変更出来ます。
※小さいフォント（96dpi） または 大きいフォント(120dpi) で正しく動作します。
※その他のサイズのフォントの場合には正しく動作しません。
・フォームを最後に閉じた時点のウィンドウのサイズや位置を記憶します。
・ブラシアップされたランチャー機能
・第2.1版で追加された機能（項目ソート・局所変数値保存・フォーム間通信）
・・・・・・・
↑
これね！
|
|
|
| ■518 / ResNo.6) |
Re[3]: モードレスB で さよなら。モードレスB を閉じる
|
□投稿者/ ジェダイの桐 -(2024/09/19(Thu) 14:16:58)
| ONnojiさん
こんにちは！
> でも、何でも自前主義、つまり「車輪の再発明」にコダワル人だったらと心配していたのです。
まさかまさかです(^^♪
便利機能を知らなかったら、自作の道で頑張るしかないですが
完成品があって使い方が分かれば 車輪の再発明 をするタイプではないのでありました(^^♪
> そこで、Thin INF_Framework を恐る恐る提案させていただいたのです。
> その結果は、快諾していただけて良かったです。(^^♪
> こういう作品は実際に使う人が現れないとブラシアップ出来ないんですよ。
想像ですが、Thin INF_Framework を受け入れてくれるユーザーは多い気がします。
想像の根拠
・間口が広い（自作フォームに組み込みやすい）
・私が 掲示板 に具体的な使い方を質問し、ONnojiさんが都度具体的解決を提示してくれている
・使い方が分かってくれば、ONnojiさん あこめさん のＨＰに仕様書・使い方の解説があるので便利機能に気付く
→ 結果、 新規開発時は INF_Framework を モダンINF_Framework にして開発する
の流れが生まれるのじゃないか？？
と、密かに勝手に思っています(^^ゞ
|
|
|
| ■519 / ResNo.7) |
Re[4]: モードレスB で さよなら。モードレスB を閉じる
|
□投稿者/ ONnoji -(2024/09/20(Fri) 12:25:33)
| ジェダイの桐さん
>>でも、何でも自前主義、つまり「車輪の再発明」にコダワル人だったらと心配していたのです。
> まさかまさかです(^^♪
> 便利機能を知らなかったら、自作の道で頑張るしかないですが
> 完成品があって使い方が分かれば 車輪の再発明 をするタイプではないのでありました(^^♪
ご明察です。
ところが、実際には完成品というのは、まず一般公開されないんですよね。
だから、他人の作ったものを利用しようという発想を持たない桐ユーザが多いのかなと思います。
ちなみに、拙作はフレームワークですから、アプリケーションと勝手が違い、使い道が理解できない人が殆どなんでしょう。
> 想像ですが、Thin INF_Framework を受け入れてくれるユーザーは多い気がします。
> 想像の根拠
> ・間口が広い（自作フォームに組み込みやすい）
> ・私が 掲示板 に具体的な使い方を質問し、ONnojiさんが都度具体的解決を提示してくれている
> ・使い方が分かってくれば、ONnojiさん あこめさん のＨＰに仕様書・使い方の解説があるので便利機能に気付く
今までフルセットにこだわっていましたから、説明が大変だったんですよ。
でも、今回はサブセットですから、組み込み方法が簡便で、説明も少なくて済みます。
大反響なんてことは絶対にないですけれど、そこそこ使ってみようかと思う人も現れるでしょうね。アハハハha
|
|
|
■記事リスト /
レス記事表示 →
[親記事-7]
|
で表示されます。
で表示されます。
Thin_INF_Framework ベータ２のご案内(58)