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

ツリー一括表示

Nomal 「目からウロコの・・・パート２」を公開.. /ONnoji (24/06/11(Tue) 16:31) #1445 1718091910.jpg/44KB
├Nomal Re[1]: 「目からウロコの・・・パート２�.. /ジェダイの桐 (24/06/14(Fri) 17:36) #1446
│└Nomal Re[2]: 「目からウロコの・・・パート２�.. /ONnoji (24/06/15(Sat) 17:45) #1447
│  └Nomal Re[3]: 「目からウロコの・・・パート２�.. /ジェダイの桐 (24/06/17(Mon) 12:06) #1448
│    └Nomal Re[4]: 「目からウロコの・・・パート２�.. /ONnoji (24/06/17(Mon) 15:17) #1449
│      └Nomal Re[5]: 「目からウロコの・・・パート２�.. /ジェダイの桐 (24/06/17(Mon) 16:22) #1450
│        └Nomal Re[6]: 「目からウロコの・・・パート２�.. /ONnoji (24/06/17(Mon) 17:33) #1451 1718614704.jpg/36KB
│          └Nomal Re[7]: 「目からウロコの・・・パート２�.. /ジェダイの桐 (24/06/18(Tue) 10:27) #1452
│            └Nomal Re[8]: 「目からウロコの・・・パート２�.. /ONnoji (24/06/18(Tue) 11:00) #1453
│              └Nomal Re[9]: 「目からウロコの・・・パート２�.. /ジェダイの桐 (24/06/18(Tue) 12:03) #1454
│                └Nomal Re[10]: 「目からウロコの・・・パート２.. /ONnoji (24/06/18(Tue) 15:54) #1455
│                  └Nomal Re[11]: 「目からウロコの・・・パート２.. /ONnoji (24/06/18(Tue) 16:48) #1456
│                    └Nomal Re[12]: 「目からウロコの・・・パート２.. /ONnoji (24/06/18(Tue) 17:05) #1457
│                      └Nomal Re[13]: 「目からウロコの・・・パート２.. /ジェダイの桐 (24/06/19(Wed) 10:53) #1458
│                        └Nomal Re[14]: 「目からウロコの・・・パート２.. /ONnoji (24/06/19(Wed) 11:28) #1459
├Nomal Re[1]: 「目からウロコの・・・パート２�.. /ONnoji (24/06/19(Wed) 15:42) #1460
│├Nomal Re[2]: 「目からウロコの・・・パート２�.. /ONnoji (24/06/19(Wed) 16:04) #1461
│├Nomal Re[2]: 「目からウロコの・・・パート２�.. /ジェダイの桐 (24/06/19(Wed) 17:02) #1462
│├Nomal Re[2]: 「目からウロコの・・・パート２�.. /尾形 (24/06/19(Wed) 18:06) #1463
││└Nomal Re[3]: 「目からウロコの・・・パート２�.. /ONnoji (24/06/19(Wed) 19:11) #1464 1718792137.jpg/57KB
│└Nomal Re[2]: 「目からウロコの・・・パート２�.. /ジェダイの桐 (24/06/20(Thu) 14:50) #1467
│  └Nomal Re[3]: 「目からウロコの・・・パート２�.. /ONnoji (24/06/20(Thu) 16:14) #1468
│    └Nomal Re[4]: 「目からウロコの・・・パート２�.. /ONnoji (24/06/21(Fri) 00:40) #1469
│      └Nomal Re[5]: 「目からウロコの・・・パート２�.. /ONnoji (24/06/21(Fri) 09:27) #1470
│        └Nomal Re[6]: 「目からウロコの・・・パート２�.. /ジェダイの桐 (24/06/21(Fri) 15:23) #1471
│          └Nomal Re[7]: 「目からウロコの・・・パート２�.. /ONnoji (24/06/24(Mon) 22:03) #1473
│            └Nomal Re[8]: 「目からウロコの・・・パート２�.. /ジェダイの桐 (24/07/18(Thu) 16:12) #1484
│              └Nomal Re[9]: 多重化のメリット　時限式タイマ�.. /ONnoji (24/07/18(Thu) 17:29) #1485
│                ├Nomal Re[10]: 多重化のメリット　時限式タイマ.. /ONnoji (24/07/18(Thu) 18:26) #1487
│                │└Nomal Re[11]: 多重化のメリット　時限式タイマ.. /ジェダイの桐 (24/07/19(Fri) 10:10) #1488
│                └Nomal Re[10]: 「目からウロコの・・・パート２.. /ジェダイの桐 (24/07/18(Thu) 18:24) #1486
│                  └Nomal Re[11]: 「多重化のメリット　時限式タイ.. /ONnoji (24/07/19(Fri) 12:59) #1489
└Nomal Re[1]: 「目からウロコの・・・パート２�.. /ONnoji (24/06/24(Mon) 19:35) #1472 1719227391.jpg/49KB


親記事　/ ▼[ 1446 ] ▼[ 1460 ] ▼[ 1472 ]
■1445 / 親階層) 　「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/11(Tue) 16:31:26)
    2024/06/11(Tue) 16:44:53 編集(投稿者)

    ＜お知らせ＞

    拙作ｗｅｂページで

    「目からウロコのデータベース桐プログラミング入門　パート２」を公開しました。

    こちら
    　↓
    桐の釣魚大全のトップ
    http://silicon7565.html.xdomain.jp/

    桐の釣魚大全のトップ > 目からウロコのデータベース桐プログラミング入門　パート２
    http://silicon7565.html.xdomain.jp/primer/primer_side_reader_part2.html

    ブラウザで表示されない場合には、Ｆ5キーを押してリロードしてください。
    　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・・・・

    　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇

    このテキストの内容は、［フォーム＋イベント処理］の初級者向けです。

    パート２で初級者の前に最初に立ちはだかる難問は、「オブジェクトって何ですか～？」です。

    なお、このテキストは拙作ｗｅｂページの「桐の釣魚大全」の

    「桐のイベント処理の入門講座」

    　新　フォームアプリケーション入門　§１
    　新　フォームアプリケーション入門　§２

    の副読本として執筆したものです。

    目次
    １０　　　　　オブジェクトって何ですか～？
    １０．１　　　オブジェクトは、パソコンの画面上の操作対象のこと
    １０．２　　　［オブジェクトのリスト］ウィンドウを使いましょう
    １１　　　　　属性ってなんですか～？
    １１．１　　　［オブジェクトの属性］ウィンドウと［オブジェクトのリスト］ウィンドウの違い
    １１．２　　　属性の取得と属性の設定
    １１．２．１　属性の取得
    １１．２．２　オブジェクトの属性と変数のデータ型
    １１．２．３　属性の設定
    １２　　　　　メソッドってなんですか～？
    １２．１　　　メソッド呼び出し
    １２．２　　　［更新モード設定］メソッドを使うか？　コマンドボタンの機能を使うか？、それが問題だ
    １２．３　　　［フォーカス設定］メソッドを使うか？　タブオーダーの設定を使うか？、それが問題だ
    １３　　　　　エラー対策のあれこれ
    １３．１　　　if ( 条件 ) ... else ... end
    １３．２　　　エラー処理コマンドはあるけれど
    １３．３　　　フォーム以外のオブジェクト名をチェックする


580×442 => 250×190

1718091910.jpg/44KB
[ □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 1445 ] / ▼[ 1447 ]
■1446 / 1階層) 　Re[1]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ジェダイの桐 -(2024/06/14(Fri) 17:36:49)
    ONnojiさん


    こんにちは！


    まさか　目からうろこのデータベース桐プログラミング入門　に　パート２が出るとは思っていませんでした！

    初級者には助かります。


    感想です。


    11.2　からの　属性の取得　設定　で勉強になった（知らなかった）部分が
    オブジェクトリストから　雛形　が取得できる事です。


    私はオブジェクト操作での　文章を書くのが得意ではありません。
    なので、雛形があれば今よりかは早くやりたい事の文章を書くことが出来ると思います(^^♪

    オブジェクト操作　って何種類も書き方があるので、結構ハードルが高く感じていました。
    なので、慣れるまでは雛形に倣って覚えていき、慣れてきたら応用すると言う、ステップアップの方法が私には分かりやすいと思います。


    12.2　更新モード設定


    私は、出来るだけコマンドボタンの機能で完結したいのですが、未だに達成できていない（理解出来ていない）事があります。


    コマンドボタンで　機能名　行追加　をした後に　機能名　表示　をしても
    表示モードになりませんでした。

    これは、仕様　なのか　私のやり方が悪い　のか未だ分かっていませんが
    解決した方法が

    メソッド呼び出し　@フォーム.更新モード設定( 6 )
    メソッド呼び出し　@フォーム.更新モード設定( 0 )

    でした。


    更新モード設定があって良かったと思う反面、なにかしっくりきませんでした(T_T)


    話がそれましたが、記述されている様に基本的にコマンドボタンの機能名で指示した方が便利だと思います(^^)/


    13.1


    if　else　end　も得意ではないのですが、


    else　end　をエラー関連処理
    .not エラーの条件


    という記述を見て、少し　モヤモヤ　が晴れた気がしました。


    エラー（偽）の条件を考えて　.not　を付ける
    かなり応用範囲が広い考え方だと感じました！

    勉強になりました！


    以上　私の感想になります。


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

▲[ 1446 ] / ▼[ 1448 ]
■1447 / 2階層) 　Re[2]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/15(Sat) 17:45:21)
    2024/06/16(Sun) 11:16:46 編集(投稿者)
    2024/06/15(Sat) 21:02:18 編集(投稿者)

    ジェダイの桐さん

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


    > まさか　目からうろこのデータベース桐プログラミング入門　に　パート２が出るとは思っていませんでした！

    本編の「新　フォームアプリケーション入門」は§１／§２で終了で続編はありません。
    実は、この種のテキストは画像を含むので非常に手間が掛かるので大変なんです。アハハハ(^^ゞ
    それに初級者向けの内容というのは膨大になるため、「ネバ―エンディング・ストーリー」なる危うさがあります。
    　　　・・・・・・・・・・・・・・・・・・

    一方、「フォームアプリケーション教書　第１部／第２部」は上級者向けの事典のような内容です。

    ちなみに、私( ONnoji )は技能の習得というレベルを「初級者・熟練した初級者・上級者・プロ・エキスパート」の５段階に分けています。※ドレイファスモデル
    ということで、いわゆる「世間の中級者」は「熟練した初級者」という扱いになります。

    そして最近、この「熟練した初級者」という技能レベルの人向けならば、（基本的に画像が無しで）文章と図解だけで十分解説出来るだろうと気が付いたのです。
    それが、「目からウロコの・・・」というシリーズの執筆の発端でした。

    ということで、文章と図解だけであれば当方の執筆の負担が少ないので、パート３等の続編を掲載しようと考えています。アハハハha

    > 11.2　からの　属性の取得　設定　で勉強になった（知らなかった）部分が
    > オブジェクトリストから　雛形　が取得できる事です。

    実は、ヘルプに書いてあるんですよ。

    こちら
    　↓
    ［桐 - ヘルプ］→［一括処理・履歴・イベント］→［入門］→［イベント処理］→［定義してみましょう］→［オブジェクト属性の参照］

    でもね、読まない人が多いんですよ。※私もちゃんと読んだことが有りませんけれどねぇ～。アハハハ

    ［オブジェクト属性の参照］はヘルプにあるのですから、「新　フォームアプリケーション入門　§１／§２」では割愛しているのですよ。

    しかし、「目からウロコの・・・」は（基本的に画像が無しで）文章と図解だけなので、今回［オブジェクト属性の参照］を題材にしました。

    > 私はオブジェクト操作での　文章を書くのが得意ではありません。
    > なので、雛形があれば今よりかは早くやりたい事の文章を書くことが出来ると思います(^^♪
    > オブジェクト操作　って何種類も書き方があるので、結構ハードルが高く感じていました。
    > なので、慣れるまでは雛形に倣って覚えていき、慣れてきたら応用すると言う、ステップアップの方法が私には分かりやすいと思います。

    ［オブジェクト操作］コマンドには、２つの書式がありますね。

    ａ．オブジェクト操作　&variableName１ = @objectName.属性名１, &variableName２ = @objectName.属性名２

    　　オブジェクト操作　@objectName.属性名１ = expression１, @objectName.属性名２ = expression２


    ｂ．オブジェクト操作　@objectName｛ &variableName１ = 属性名１, &variableName２ = 属性名２ ｝

    　　オブジェクト操作　@objectName｛ 属性名１ = expression１, 属性名２ = expression２ ｝

    ［オブジェクト属性の参照］の雛形は、ａ形式ですね。

    ｂ形式は、雛形を更に書き直さなければなりませんので手間が掛かります。

    しかし、慣れてしまうとそれ程の手間もかかりませんので、最近では私( ONnoji )はｂ形式の方を使っていますね。

    どちらでも結果は同じなので、単に好みの問題ですね。

    > 12.2　更新モード設定
    > 私は、出来るだけコマンドボタンの機能で完結したいのですが、未だに達成できていない（理解出来ていない）事があります。
    > 解決した方法が
    > メソッド呼び出し　@フォーム.更新モード設定( 6 )
    > メソッド呼び出し　@フォーム.更新モード設定( 0 )
    > でした。

    これですね
    　↓
    　オブジェクト名： cmd予定追加
    　標題　　　　　： 予定追加

    　　機能名　　　　機能パラメータリスト
    　1 表示　　　　　確定する
    　2 手続き実行　　cmd予定追加Click
    　3 訂正　　　　 "txt日付_入力用"
    　4 なし

    手続き定義開始　cmd予定追加Click()

    　メソッド呼び出し　@フォーム.更新モード設定( 6 )
    　項目値代入　[日付] = &m日付, [予定] = &m予定
    　メソッド呼び出し　@フォーム.更新モード設定( 0 )

    　&m日付 = #u, &m予定 = #u

    手続き定義終了

    もしも、私だったら以下のようにしますよ。

    　オブジェクト名： cmd予定追加
    　標題　　　　　： 予定追加

    　　機能名　　　　機能パラメータリスト
    　1 表示
    　2 手続き実行　　cmd予定追加Click
    　3 訂正　　　　 "txt日付_入力用"
    　4 なし

    手続き定義開始　cmd予定追加Click()
    　変数宣言　自動，整数｛ &status ｝

    　** cf.桐ヘルプ［行追加］コマンド　 編集対象表の最後に新規行を追加します。１回の実行で、１件の行を追加します。
    　行追加　終了状態 = &status,　[日付] = &m日付, [予定] = &m予定

    　** &status
    　** 戻り値　説明
    　** 1 　　　正常に終了した
    　** 0　 　　共有違反以外のエラーが発生した
    　**-2　 　　他の利用者が置換や併合などの処理を実行中（ファイル排他）

    　&m日付 = #u　/* 代入をマルチステートメント風に書くと水平方向に視線が移動するので変数名が探し難くなります */
    　&m予定 = #u

    手続き定義終了

    > コマンドボタンで　機能名　行追加　をした後に　機能名　表示　をしても
    > 表示モードになりませんでした。
    > これは、仕様　なのか　私のやり方が悪い　のか未だ分かっていませんが
    > 更新モード設定があって良かったと思う反面、なにかしっくりきませんでした(T_T)

    桐だけしか使っていない人の場合には当たり前のことですが、
    それ以外の人にとっては、桐に［更新モード］があることを不思議に感じた人が多いのではないでしょうかね。

    つまり、［更新モード］があるから超・面倒臭いと思いますよね。
    でも、ＤＯＳ桐の時から存在するので仕方がないですね。

    さて、コマンドボタンの機能名：行挿入　というのは、

    　指定されたオブジェクト名の場所にフォーカスを移動して、
    　行挿入状態にする。

    ということなんですよね。

    つまり、

    ・メニューバーの［行操作］メニュー→［行挿入］を実行する
    　または
    ・ファンクションキーのＡ｜Ｆ３（行挿入）を押す

    と同じなんです。

    決して、自動的に１行追加するわけでは無いんです。だって、［Esc］ キー等でキャンセルできますからねぇ～。

    コマンドボタンの機能名を見て「きっと、こうだろう！」と予想するのは構いませんが、本当に予想通りかは試してみないと分かりませんね。

    もちろん、経験済みのコマンドボタンの機能名ならば、既知なのですぐに判断できますが・・・

    ということで、慣れない間は、コマンドボタンのヘルプを確認してください。

    こちら
    　↓
    １２．５　コマンドボタンの機能グループ・機能名・機能パラメータ・説明・起動条件など｜桐の釣魚大全のトップ > フォームアプリケーション教書　第１部
    http://silicon7565.html.xdomain.jp/guide/guide_Part1.htm#section12-5

    １２．６　コマンドボタンでよくある勘違い｜桐の釣魚大全のトップ > フォームアプリケーション教書　第１部
    http://silicon7565.html.xdomain.jp/guide/guide_Part1.htm#section12-6

    > 話がそれましたが、記述されている様に基本的にコマンドボタンの機能名で指示した方が便利だと思います(^^)/

    コマンドボタンは便利ですが、決して万能ではありませんね。

    イチにも二にも経験ですから、だんだんとコツを掴んで上手になりますよ。

    ｐ．ｓ．

    > コマンドボタンで　機能名　行追加　をした後に　機能名　表示　をしても
    > 表示モードになりませんでした。
    > これは、仕様　なのか　私のやり方が悪い　のか未だ分かっていませんが
    > 更新モード設定があって良かったと思う反面、なにかしっくりきませんでした(T_T)

    ↑これを再現しようと試みましたが出来ませんでした。

    具体的に

    １．コマンドボタンの設定
    ２．機能名：手続き実行で実行する一般手続きの内容

    を示していただければ、理由を解明できるかもしれません。



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

▲[ 1447 ] / ▼[ 1449 ]
■1448 / 3階層) 　Re[3]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ジェダイの桐 -(2024/06/17(Mon) 12:06:36)
    ONnojiさん


    > それに初級者向けの内容というのは膨大になるため、「ネバ―エンディング・ストーリー」なる危うさがあります。
    > 　　　・・・・・・・・・・・・・・・・・・


    本当にそうですよね・・・
    どこまで理解しているか分からないと、どこまで掘り下げてもキリがないですよね(T_T)


    > そして最近、この「熟練した初級者」という技能レベルの人向けならば、（基本的に画像が無しで）文章と図解だけで十分解説出来るだろうと気が付いたのです。
    > それが、「目からウロコの・・・」というシリーズの執筆の発端でした。
    >
    > ということで、文章と図解だけであれば当方の執筆の負担が少ないので、パート３等の続編を掲載しようと考えています。アハハハha


    もしも、アップロードされたら必ず拝見させて頂きますm(__)m


    > 実は、ヘルプに書いてあるんですよ。
    >
    > こちら
    > 　↓
    > ［桐 - ヘルプ］→［一括処理・履歴・イベント］→［入門］→［イベント処理］→［定義してみましょう］→［オブジェクト属性の参照］
    >
    > でもね、読まない人が多いんですよ。※私もちゃんと読んだことが有りませんけれどねぇ～。アハハハ


    確認漏れでした。
    実際にヘルプを見る時は、気になる事がある時　困った時　だと思います。


    今回、実際に困ったのに雛形の存在に気づけなかったと言う事は、
    まだまだだなぁ～と思ってしまいます。


    > ［オブジェクト操作］コマンドには、２つの書式がありますね。
    >
    > ａ．オブジェクト操作　&variableName１ = @objectName.属性名１, &variableName２ = @objectName.属性名２
    >
    > 　　オブジェクト操作　@objectName.属性名１ = expression１, @objectName.属性名２ = expression２
    >
    >
    > ｂ．オブジェクト操作　@objectName｛ &variableName１ = 属性名１, &variableName２ = 属性名２ ｝
    >
    > 　　オブジェクト操作　@objectName｛ 属性名１ = expression１, 属性名２ = expression２ ｝
    >
    > ［オブジェクト属性の参照］の雛形は、ａ形式ですね。
    >
    > ｂ形式は、雛形を更に書き直さなければなりませんので手間が掛かります。
    >
    > しかし、慣れてしまうとそれ程の手間もかかりませんので、最近では私( ONnoji )はｂ形式の方を使っていますね。
    >
    > どちらでも結果は同じなので、単に好みの問題ですね。


    選択出来る事はよい事ですよね！
    ただ、プログラムの中で、aパターン　ｂパターン　が混在すると
    見にくくなると思うので、どちらかで統一してプログラミングする様に
    心がけます(^^♪
    （といっても、混在しそうですが・・・）


    > もしも、私だったら以下のようにしますよ。
    >
    > 　オブジェクト名： cmd予定追加
    > 　標題　　　　　： 予定追加
    >
    > 　　機能名　　　　機能パラメータリスト
    > 　1 表示
    > 　2 手続き実行　　cmd予定追加Click
    > 　3 訂正　　　　 "txt日付_入力用"
    > 　4 なし
    >
    > 手続き定義開始　cmd予定追加Click()
    > 　変数宣言　自動，整数｛ &status ｝
    >
    > 　** cf.桐ヘルプ［行追加］コマンド　 編集対象表の最後に新規行を追加します。１回の実行で、１件の行を追加します。
    > 　行追加　終了状態 = &status,　[日付] = &m日付, [予定] = &m予定
    >
    > 　** &status
    > 　** 戻り値　説明
    > 　** 1 　　　正常に終了した
    > 　** 0　 　　共有違反以外のエラーが発生した
    > 　**-2　 　　他の利用者が置換や併合などの処理を実行中（ファイル排他）
    >
    > 　&m日付 = #u　/* 代入をマルチステートメント風に書くと水平方向に視線が移動するので変数名が探し難くなります */
    > 　&m予定 = #u
    >
    > 手続き定義終了


    プログラム例ありがとうございます。


    このプログラムでやってみたのですが、
    3 訂正　　　　 "txt日付_入力用"
    になりませんでした。


    試しに、　機能名　訂正　→　機能名　表示　にしてみましたが　表示モードになりません。


    トレース出力で　&status　を見てみると　1　になっているので　正常に終了をしています。


    > ということで、慣れない間は、コマンドボタンのヘルプを確認してください。
    >
    > こちら
    > 　↓
    > １２．５　コマンドボタンの機能グループ・機能名・機能パラメータ・説明・起動条件など｜桐の釣魚大全のトップ > フォームアプリケーション教書　第１部
    > http://silicon7565.html.xdomain.jp/guide/guide_Part1.htm#section12-5
    >
    > １２．６　コマンドボタンでよくある勘違い｜桐の釣魚大全のトップ > フォームアプリケーション教書　第１部
    > http://silicon7565.html.xdomain.jp/guide/guide_Part1.htm#section12-6


    はい！
    読み込んで勉強します！


    >>話がそれましたが、記述されている様に基本的にコマンドボタンの機能名で指示した方が便利だと思います(^^)/
    >
    > コマンドボタンは便利ですが、決して万能ではありませんね。
    >
    > イチにも二にも経験ですから、だんだんとコツを掴んで上手になりますよ。


    こうやって、アドバイスを頂けるので少しづつですが、やりたい事が実現出来始めています。
    ありがとうございます！


    > ｐ．ｓ．
    >
    >>コマンドボタンで　機能名　行追加　をした後に　機能名　表示　をしても
    >>表示モードになりませんでした。
    >>これは、仕様　なのか　私のやり方が悪い　のか未だ分かっていませんが
    >>更新モード設定があって良かったと思う反面、なにかしっくりきませんでした(T_T)
    >
    > ↑これを再現しようと試みましたが出来ませんでした。
    >
    > 具体的に
    >
    > １．コマンドボタンの設定
    > ２．機能名：手続き実行で実行する一般手続きの内容
    >
    > を示していただければ、理由を解明できるかもしれません。


    申し訳ありません。
    手続き定義中　の　行追加と混同して書いてしまいました。

    下記の通り

    　機能名　　　　機能パラメータリスト
    　1 表示　　　　　
    　2 行追加
    　3 手続き実行　　cmd予定追加Click　　　　
    　4 表示　


    手続き定義開始　cmd予定追加Click()

    　項目値代入　[日付] = &m日付, [予定] = &m予定
    　

    　&m日付 = #u
    　&m予定 = #u

    手続き定義終了


    であれば、ちゃんと表示モードになります。


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

▲[ 1448 ] / ▼[ 1450 ]
■1449 / 4階層) 　Re[4]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/17(Mon) 15:17:11)
    2024/06/17(Mon) 16:12:12 編集(投稿者)

    >> コマンドボタンで　機能名　行追加　をした後に　機能名　表示　をしても
    >> 表示モードになりませんでした。
    >>
    >> これは、仕様　なのか　私のやり方が悪い　のか未だ分かっていませんが
    >> 解決した方法が
    >>
    >> メソッド呼び出し　@フォーム.更新モード設定( 6 )
    >> メソッド呼び出し　@フォーム.更新モード設定( 0 )
    >>
    >> でした。

    > これですね
    > 　↓
    > 　オブジェクト名： cmd予定追加
    > 　標題　　　　　： 予定追加
    >
    > 　　機能名　　　　機能パラメータリスト
    > 　1 表示　　　　　確定する
    > 　2 手続き実行　　cmd予定追加Click
    > 　3 訂正　　　　 "txt日付_入力用"
    > 　4 なし
    >
    > 手続き定義開始　cmd予定追加Click()
    >
    > 　メソッド呼び出し　@フォーム.更新モード設定( 6 )
    > 　項目値代入　[日付] = &m日付, [予定] = &m予定
    > 　メソッド呼び出し　@フォーム.更新モード設定( 0 )
    >
    > 　&m日付 = #u, &m予定 = #u
    >
    > 手続き定義終了

    この件↑ですが、ジェダイの桐さんと当方の双方で認識が違うように思うようになりました。

    そこで、出発点に戻って確認したいのです。

    ■スケジュール表.wfx

    　フォーム
    　├ ファミリ
    　├ ワークスペース
    　│　└ cmdStartUp
    　├ フォームヘッダ部
    　│　├ lbl日付
    　│　├ a予定　　　　　　　　　　　　　　　　　　　　　　　　　　　　機能名　　機能パラメータリスト
    　│　├ txt日付_入力用　　　　　０．フォームが開いた時 cmdStartUp で 4.訂正　　"txt日付_入力用"
    　│　│　└ lbl日付_入力用 ←─ １．最初に入力
    　│　├ txt予定_入力用
    　│　│　└ lbl予定_入力用 ←─ ２．次に入力
    　│　├ cmd予定追加　　　　←─ ３．コマンドボタンを実行
    　│　├ cmd当日
    　│　├ cmd週間
    　│　├ cmd絞込_式
    　│　├ cmd絞込_値
    　│　├ cmd前週
    　│　├ cmd次週
    　│　├ cmd今月
    　│　├ cmd前月
    　│　└ cmd次月
    　└ フォーム明細部
    　　　├ 行セレクタ
    　　　├ txt日付
    　　　└ txt予定


    上の図解のように０．１．２．３．の順で実行するわけですよね。

    そこで、確認したいのは、このシーケンス（手順）を実行した後に、

    フォーカスがあるオブジェクトをどのオブジェクトにしたいのでしょうか？

    もしも、そのオブジェクトがテキストボックスであれば、その時にキャレット（入力カーソル）が表示されている必要があるのでしょうか？？


    ｐ．ｓ．

    最初に、

    　項目値代入　[日付] = &m日付, [予定] = &m予定

    ↑を見付けた時に変なことするなぁ～と思ったんですよ。

    なぜならば、［項目値代入］コマンドは、

    　　△項目値の入力中のみ実行可能（項目訂正、行訂正、行挿入、行追加）。

    　　・入力中の項目値を設定または変更します。フォーム上に表示していない項目の値や、
    　　　オブジェクトの属性で編集禁止にしている項目の値も、このコマンドで指定することができます。
    　　・このコマンドは、フォームのイベントハンドラ内に記述します。一括処理から実行することはできません。
    　　・つぎの会話処理を行なっているあいだに実行する、イベントハンドラに記述できます。
    　　　　項目訂正（表の項目訂正）
    　　　　行訂正
    　　　　行挿入
    　　　　行追加
    　　・項目値を編集するオブジェクトがひとつもないとき、またはフォームが表示状態のときは、実行することができません。

    ［桐 - ヘルプ］にある、"このコマンドは、フォームのイベントハンドラ内に記述します。" ← という所がどうも心に引っかかったのです。

    だから、（あくまでも私の場合にですが）あまり使うことがないコマンドなんですよ。

    > 　メソッド呼び出し　@フォーム.更新モード設定( 6 )
    > 　項目値代入　[日付] = &m日付, [予定] = &m予定

    でも、↑このように挿入モード遷移した状態ならば、アリなんだろうと思った次第です。


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

▲[ 1449 ] / ▼[ 1451 ]
■1450 / 5階層) 　Re[5]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ジェダイの桐 -(2024/06/17(Mon) 16:22:13)
    2024/06/18(Tue) 10:27:38 編集(投稿者)

    ONnojiさん


    こんにちは！


    > ■スケジュール表.wfx
    >
    > 　フォーム
    > 　├ ファミリ
    > 　├ ワークスペース
    > 　│　└ cmdStartUp
    > 　├ フォームヘッダ部
    > 　│　├ lbl日付
    > 　│　├ a予定　　　　　　　　　　　　　　　　　　　　　　　　　　　　機能名　　機能パラメータリスト
    > 　│　├ txt日付_入力用　　　　　０．フォームが開いた時 cmdStartUp で 4.訂正　　"txt日付_入力用"
    > 　│　│　└ lbl日付_入力用 ←─ １．最初に入力
    > 　│　├ txt予定_入力用
    > 　│　│　└ lbl予定_入力用 ←─ ２．次に入力
    > 　│　├ cmd予定追加　　　　←─ ３．コマンドボタンを実行
    > 　│　├ cmd当日
    > 　│　├ cmd週間
    > 　│　├ cmd絞込_式
    > 　│　├ cmd絞込_値
    > 　│　├ cmd前週
    > 　│　├ cmd次週
    > 　│　├ cmd今月
    > 　│　├ cmd前月
    > 　│　└ cmd次月
    > 　└ フォーム明細部
    > 　　　├ 行セレクタ
    > 　　　├ txt日付
    > 　　　└ txt予定
    >
    >
    > 上の図解のように０．１．２．３．の順で実行するわけですよね。
    >
    > そこで、確認したいのは、このシーケンス（手順）を実行した後に、
    >
    > フォーカスがあるオブジェクトをどのオブジェクトにしたいのでしょうか？
    >
    > もしも、そのオブジェクトがテキストボックスであれば、その時にキャレット（入力カーソル）が表示されている必要があるのでしょうか？？


    0. 1. 2. 3.　の後　1. ( txt日付_入力用 )　にフォーカスされ　キャレットが表示されている事が狙いでした。


    基本的に　txt日付　と　txt予定に直接入力はせずに
    txt日付_入力用　と　 txt予定_入力用　で入力した物を　
    txt日付　と　txt予定　に行追加する狙いです。


    なので、フォームを開いた時　txt日付_入力用　が訂正モードになっているし
    cmd予定追加　をクリックした後は　txt日付_入力用　にフォーカスが移動していて　且つ　訂正モード　になっていて欲しいです。


    0. 1. 2. 3.　→　1. 2. 3.　→　1. 2. 3.　・・・
    が狙いでした。


    添付したファイルですと、　0. 1. 2. 3.　までは狙い通りなのですが、
    その後、表示モードにならず　エンターを押すと行追加が繰り返し行われます。


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

▲[ 1450 ] / ▼[ 1452 ]
■1451 / 6階層) 　Re[6]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/17(Mon) 17:33:36)
    2024/06/17(Mon) 22:34:41 編集(投稿者)

    > 0. 1. 2. 3.　→　1. 2. 3.　→　1. 2. 3.　・・・
    > が狙いでした。

    なるほど、スケジュール表2.wfx の場合には、

    現行では次のようにすると、一見解決したようになります。
    　　　　　　　　　　　　　・・・・・・・・・

    １．cmd予定追加 (ｺﾏﾝﾄﾞﾎﾞﾀﾝ)の［フォーカスの設定］属性を

    　×　許可　　　※許可では、コマンドボタンの機能を実行した後で、フォーカスがボタンに戻ってしまいます

    　〇　自動

    に変更します。

    ２．一般手続き：cmd予定追加Click() を次のように変更します・

    手続き定義開始　cmd予定追加Click()
    　変数宣言　自動, 整数　{ &status }

    　行追加　終了状態 = &status, [日付] = &m日付, [予定] = &m予定

    　ジャンプ　行番号 = 最終　/* これを挿入 */

    　&m日付 = #u
    　&m予定 = #u

    手続き定義終了


    でもね、根本的な問題があるんですよ。

    現行では

    次の↓［開始時実行］コマンドボタンで

    　オブジェクト名： cmdStartUp
    　標題　　　　　： StartUp

    　　機能名　　　　　　機能パラメータリスト
    　1 表示
    　2 絞り込み_比較式　 #日時日付(#日時値) <= #日時日付([日付]) <= #日時日付( #日数加算(#日時値, 7 ) )
    　3 並べ替え_昇順　　 [日付]
    　4 訂正　　　　　　　 "txt日付_入力用"


    絞り込みをしていますね。

    そして、レコードが絞り込まれた結果が０行ではありませんね。
    　　　　・・・・・・・・・・・・・・・・・・・・・・・

    だから気が付かなかったのですが、

    実は、

    ・編集対象表が０行の時　※これは先頭行ですが、終端行でもあります。

    ・編集対象表の現在行が終端行の時

    レコードが無いのですから、どう逆立ちしても［訂正］モードには遷移できないのです。

    ここが、編集対象表が無いNULLフォームと編集対象表が有るフォームとの大きな違いです。ガ～～～ン

    ということで、編集対象表が０行の時の対策をしなければなりませんが・・・

    しかし、私にはお世辞にもスマートなアプローチに思えませんので、具体策の提示は差し控えます。
    　　　　・・・・・・・・・・・・・・・・・・・・・・・・

    だって、０行の時だけの対策って変でしょう。これは個人のセンスの問題ですけれどね・・・アハハハ

    私は、無理やり出来るようにするよりも、余計な手を掛けずに済ます方を選びたいですね。

    ということで、

    編集対象表が有る普通のフォームの場合には、

    フォームヘッダ部に検索する値を入力するテキストボックスは良いと思いますが　※レコードが無ければ［検索］も［絞り込み］も意味が無いです

    今回のような入力用のテキストボックスは向いていません。

    何故ならば、繰り返しになりますが、編集対象表が０行の時があるからです。

    ｐ．ｓ．

    コマンドボタンの［フォーカスの設定］属性は、編集対象表が有るフォームでは "自動" のまま使うのが普通ですよ。

    変更する場合は、どうしても都合が悪い時だけにしますね。

    ｐ．ｐ．ｓ．

    拙作のオートフォームのヘッダ部に［固定　▼］［項目　▼］と表示しているテキストボックスがあります。

    これは（見た目はボタンですが）テキストボックスですので、

    入力支援ボタンのドロップダウンリストを出すために訂正モードにしたいのですが、終端行ではこれが出来ません。

    そこで仕方なく、

    　&msg = "この機能は表示ﾓｰﾄﾞの場合、終端行では実行できません"

    というメッセージボックスを表示しています。

    もちろん、行挿入モードに遷移すれば出来るんですよ。

    でも「出来れば何でもＯＫという無節操な態度」は、私のポリシーではないのです。

    行を登録するつもりがないのに［表示］モードから［行挿入］モードに遷移するのが意地でも嫌なんですね。アハハハha
    ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    これは私( ONnoi )個人のセンスですよ。アハハハha

414×316 => 250×190

1718614704.jpg/36KB
[ 親 1445 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 1451 ] / ▼[ 1453 ]
■1452 / 7階層) 　Re[7]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ジェダイの桐 -(2024/06/18(Tue) 10:27:22)
    ONnojiさん


    おはようございます！


    > ２．一般手続き：cmd予定追加Click() を次のように変更します・
    >
    > 手続き定義開始　cmd予定追加Click()
    > 　変数宣言　自動, 整数　{ &status }
    >
    > 　行追加　終了状態 = &status, [日付] = &m日付, [予定] = &m予定
    >
    > 　ジャンプ　行番号 = 最終　/* これを挿入 */
    >
    > 　&m日付 = #u
    > 　&m予定 = #u
    >
    > 手続き定義終了


    ジャンプ　行番号 = 最終　を入れる事で解決しました。
    メソッド呼び出しで更新モードを使用するより　分かりやすいです。


    > でもね、根本的な問題があるんですよ。
    >
    > 現行では
    >
    > 次の↓［開始時実行］コマンドボタンで
    >
    > 　オブジェクト名： cmdStartUp
    > 　標題　　　　　： StartUp
    >
    > 　　機能名　　　　　　機能パラメータリスト
    > 　1 表示
    > 　2 絞り込み_比較式　 #日時日付(#日時値) <= #日時日付([日付]) <= #日時日付( #日数加算(#日時値, 7 ) )
    > 　3 並べ替え_昇順　　 [日付]
    > 　4 訂正　　　　　　　 "txt日付_入力用"
    >
    >
    > 絞り込みをしていますね。
    >
    > そして、レコードが絞り込まれた結果が０行ではありませんね。
    > 　　　　・・・・・・・・・・・・・・・・・・・・・・・
    >
    > だから気が付かなかったのですが、
    >
    > 実は、
    >
    > ・編集対象表が０行の時　※これは先頭行ですが、終端行でもあります。
    >
    > ・編集対象表の現在行が終端行の時
    >
    > レコードが無いのですから、どう逆立ちしても［訂正］モードには遷移できないのです。


    この事は知らないと分からなかったです。
    というよりか、そもそもの出発点として


    > 編集対象表が有る普通のフォームの場合には、
    >
    > フォームヘッダ部に検索する値を入力するテキストボックスは良いと思いますが　※レコードが無ければ［検索］も［絞り込み］も意味が無いです
    >
    > 今回のような入力用のテキストボックスは向いていません。


    入力用テキストボックスが　ヘッダ部にある事で複雑になってしまったのですね(T_T)


    NULLフォーム　で　スケジュール表.TBX　に行追加する方法が　入力方法としては向いているのですね(^^♪　


    勉強になりました！


    何故、ヘッダ部に入力用テキストボックスを置いたかと言うと、直感的に分かりやすいかな？と思ったからなんです。


    > ｐ．ｓ．
    >
    > コマンドボタンの［フォーカスの設定］属性は、編集対象表が有るフォームでは "自動" のまま使うのが普通ですよ。
    >
    > 変更する場合は、どうしても都合が悪い時だけにしますね。


    そうだったんですね！
    教えて頂きありがとうございますm(__)m


    > ｐ．ｐ．ｓ．
    >
    > 拙作のオートフォームのヘッダ部に［固定　▼］［項目　▼］と表示しているテキストボックスがあります。
    >
    > これは（見た目はボタンですが）テキストボックスですので、
    >
    > 入力支援ボタンのドロップダウンリストを出すために訂正モードにしたいのですが、終端行ではこれが出来ません。
    >
    > そこで仕方なく、
    >
    > 　&msg = "この機能は表示ﾓｰﾄﾞの場合、終端行では実行できません"
    >
    > というメッセージボックスを表示しています。
    >
    > もちろん、行挿入モードに遷移すれば出来るんですよ。
    >
    > でも「出来れば何でもＯＫという無節操な態度」は、私のポリシーではないのです。
    >
    > 行を登録するつもりがないのに［表示］モードから［行挿入］モードに遷移するのが意地でも嫌なんですね。アハハハha
    > ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    >
    > これは私( ONnoi )個人のセンスですよ。アハハハha


    確かに　出来れば何でもOK　という考え方は実際あると思うのです。
    しかし、出来るからといって　無秩序にやってしまうと　整合性が取れなくなり
    結果として管理（保全）が出来なくなると思うんです。


    私が　フォーム+イベント　をやってみようと本格的に思った事があります。


    桐質問掲示板　■14187　行制約について　で質問した時
    ONnojiさんに　行制約で出来るか出来ないかと言えば　近しい事は出来たとしても　表をそのまま使って、［行制約］で入力許可／入力禁止をというアプローチは無理筋　だけど　フォーム+イベント　であれば実現可能　と教えて貰いました。


    更にサンプルまで作成して頂き、思った通りの事が実現出来ました。


    あの時、むりやり　行制約　でやりたい事を実現してしまうと　無秩序となり
    管理が難しくなっていたと思います。


    なので、今私が心がけていることは、

    1、単純な方法で進めたい
    2、桐の機能としても、使用する人に対しても不自然でない素直な方法

    で　フォーム作りをしています。


    なので、　機能名　訂正　があるのに、メソッド呼び出し　更新モード設定
    を使用する事が　いまいちシックリこなかった（と言うよりは、不自然に感じた）のです。


    今回教えて頂いた方法は、表面上の救済処置なのでしょうが、更新モードを使用するよりシックリきます。


    （これこそ、初級者の私が感じるセンスだけの問題かもしれませんけれど(◎_◎;)）


    目からウロコのデータベース桐プログラミング入門　パート２　のフィードバックを書き込んでいたのに、色々教えて頂きありがとうございましたm(__)m


    ONnojiさんが立てられたスレッドなので、私が　解決済み！　を押すのは何だか変なので押しませんが、個人的に　解決済み！　です！
[ 親 1445 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 1452 ] / ▼[ 1454 ]
■1453 / 8階層) 　Re[8]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/18(Tue) 11:00:29)
    2024/06/18(Tue) 11:03:38 編集(投稿者)

    >>編集対象表が有る普通のフォームの場合には、
    >>フォームヘッダ部に検索する値を入力するテキストボックスは良いと思いますが　※レコードが無ければ［検索］も［絞り込み］も意味が無いです
    >>今回のような入力用のテキストボックスは向いていません。
    >
    > 入力用テキストボックスが　ヘッダ部にある事で複雑になってしまったのですね(T_T)
    > NULLフォーム　で　スケジュール表.TBX　に行追加する方法が　入力方法としては向いているのですね(^^♪　

    別の方法を考えましたので、現在試しています。

    出来上がったらサンプルをアップしますので、しばらくお待ちください。



    > 何故、ヘッダ部に入力用テキストボックスを置いたかと言うと、直感的に分かりやすいかな？と思ったからなんです。

    編集対象表があるフォームの場合には、コマンドボタンまたはメニュー・ファンクションキーの直接操作で行を挿入・追加するのが面倒がなくて良いです。

    これは、フォームといえども編集対象表が有るフォームは、表の編集と大差ないからです。

    NULLフォームの場合には、編集対象表が無いですから、フォームで変数を編集するのは簡単ですね。

    ちなみに、ＤＯＳ桐のフォームでは変数は編集できなかったんですよ。項目しか編集できなかったのです。



    > 何故、ヘッダ部に入力用テキストボックスを置いたかと言うと、直感的に分かりやすいかな？と思ったからなんです。

    これっ↑て、エクセルのユーザインタフェースから思い付きましたか？？？



    > 確かに　出来れば何でもOK　という考え方は実際あると思うのです。
    > しかし、出来るからといって　無秩序にやってしまうと　整合性が取れなくなり
    > 結果として管理（保全）が出来なくなると思うんです。

    その通りですね。ただ我武者羅にやるのはスマートではありません。

    その時には気分が良くても、後で大変な目に合うかもしれませんからね。アハハハha

    > あの時、むりやり　行制約　でやりたい事を実現してしまうと　無秩序となり
    > 管理が難しくなっていたと思います。
    > なので、今私が心がけていることは、
    > 1、単純な方法で進めたい
    > 2、桐の機能としても、使用する人に対しても不自然でない素直な方法
    > で　フォーム作りをしています。
    > なので、　機能名　訂正　があるのに、メソッド呼び出し　更新モード設定
    > を使用する事が　いまいちシックリこなかった（と言うよりは、不自然に感じた）のです。
    > 今回教えて頂いた方法は、表面上の救済処置なのでしょうが、更新モードを使用するよりシックリきます。

    センスが良いと思いますよ。大切にしてください。


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

▲[ 1453 ] / ▼[ 1455 ]
■1454 / 9階層) 　Re[9]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ジェダイの桐 -(2024/06/18(Tue) 12:03:06)
    ONnojiさん


    > 別の方法を考えましたので、現在試しています。
    >
    > 出来上がったらサンプルをアップしますので、しばらくお待ちください。


    ありがとうございます。


    > 編集対象表があるフォームの場合には、コマンドボタンまたはメニュー・ファンクションキーの直接操作で行を挿入・追加するのが面倒がなくて良いです。
    >
    > これは、フォームといえども編集対象表が有るフォームは、表の編集と大差ないからです。


    言われてみれば確かにそうですね・・・
    直接入力の方が、分かりやすいし、今回のフォームに対しては一番素直だと思いました。


    >>何故、ヘッダ部に入力用テキストボックスを置いたかと言うと、直感的に分かりやすいかな？と思ったからなんです。
    >
    > これっ↑て、エクセルのユーザインタフェースから思い付きましたか？？？


    いえ。単純にそう思ってしまったのです。
    しかも、自分自身で単純で素直が良いと言っておきながら、
    イベント過多症候群の様な状態になっていました・・・


    入力テキストがあった方が良いだろうと、思い込んで　もしくは　決めつけてしまいました。
    （今にしてみれば、少しフォームが使える様になったから機能を詰め込もうと無意識に思っていたのだと思います(T_T)）


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

▲[ 1454 ] / ▼[ 1456 ]
■1455 / 10階層) 　Re[10]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/18(Tue) 15:54:57)
    2024/06/18(Tue) 15:58:28 編集(投稿者)

    ［トレース出力］ウィンドウを観察していると・・・

    フォームが開いた時、

    　"D:\kiri10s\1718608933\スケジュール管理2.kex"を一括処理実行で開きました
    　エラー　:KD1618:比較できないデータ型の組合わせがあります　...値) <= #日時日付([日付]) <=←(D:\kiri10s\1718608933\スケジュール表.TBX )

    こいうエラーが表示されます。

    これは［開始時実行］コマンドボタンを実行した際に表示されていました。

    　オブジェクト名： cmdStartUp
    　標題　　　　　： StartUp

    　　機能名　　　　　　機能パラメータリスト
    　1 表示
    　2 絞り込み_比較式　 #日時日付(#日時値) <= #日時日付([日付]) <= #日時日付( #日数加算(#日時値, 7 ) )
    　3 並べ替え_昇順　　 [日付]
    　4 訂正　　　　　　　 "txt日付_入力用"

    これを実行した時に

    　2 絞り込み_比較式　 #日時日付(#日時値) <= #日時日付([日付]) <= #日時日付( #日数加算(#日時値, 7 ) )

    ↑の部分を実行する時に表示されています。

    しかし、絞り込みはちゃんとできています。

    試しに、ヘッダの［cmd絞込_式］ボタンを実行して比較式ダイアログに

    　#日時日付(#日時値) <= #日時日付([日付]) <= #日時日付( #日数加算(#日時値, 7 ) )

    を張り付けて実行すると、［トレース出力］ウィンドウにエラーは表示されません。

    さらに調べると

    ＯＫ　#日時日付(#日時値) <= #日時日付([日付])

    ＯＫ　#日時日付([日付]) <= #日時日付( #日数加算(#日時値, 7 ) )

    ＮＧ　#日時日付(#日時値) <= #日時日付([日付]) <= #日時日付( #日数加算(#日時値, 7 ) )

    という具合に、expression1 <= val <= expression2

    の時だけエラーを表示していることが分かりました。

    しかし、実行結果は正しいのです。アハハハha

    ということで、

    ＜改良案１＞

    　オブジェクト名： cmdStartUp
    　標題　　　　　： StartUp

    　　機能名　　　　　　機能パラメータリスト
    　1 絞り込み_比較式　 #日時日付(#日時値) <= #日時日付([日付])　　　　　　　　　←　一段め絞り込み
    　2 絞り込み_比較式　 #日時日付([日付]) <= #日時日付( #日数加算(#日時値, 7 ) ) ←　二段め絞り込み
    　3 並べ替え_昇順　　 [日付]
    　4 訂正　　　　　　　"txt日付_入力用"

    ※↑本当は　解除　＊　が必要なのですが・・・


    ＜改良案２＞

    　オブジェクト名： cmdStartUp
    　標題　　　　　： cmdStartUp：開始時実行コマンド：（cmd週間とほぼ同じ設定）

    　　機能名　　　　　機能パラメータリスト
    　1 表示
    　2 解除　　　　　　*
    　3 手続き実行　　　cmd週間Click
    　4 訂正　　　　　　"txt日付_入力用"

    　手続き定義開始　cmd週間Click()

    　　** 解除　＊
    　　並べ替え　{[日付] 昇順 }
    　　絞り込み　[日付]　{ #日時日付(#日時値) <= #日時日付([]) <= #日時日付( #日数加算(#日時値, 7 ) ) }

    　手続き定義終了

    　※一般手続き：cmd週間Click()側 に ［解除　＊］コマンドがあった方が良いのでは？？？？
    　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    のように変更することをお勧めします。

    ＜改良案２＞の方がおススメですね。(^^ok

    繰り返しになりますが、エラーが表示されていますが、正しく実行されているようです。

    ですが、今後エラーに気が付いて後戻りして調べるよりは、エラーが表示されないように処置しておくのがベターだと思います。

    取り急ぎお知らせまで。

    ｐ．ｓ．

    サンプルは無事に進捗していますが、エラーを調べていましたので時間を取られてまだ完成していません。

    こうご期待。(^^ゞ


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

▲[ 1455 ] / ▼[ 1457 ]
■1456 / 11階層) 　Re[11]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/18(Tue) 16:48:15)
    2024/06/18(Tue) 16:49:10 編集(投稿者)

    こんな実験をしてみました。

    手続き定義開始　cmdTestClick( )
    　変数宣言　自動，文字列｛ &icon, &title = "cmdTestClick( )", &msg ｝
    　変数宣言　自動，整数　｛ &trace ｝

    　&trace = 1
    　条件　( &trace )　トレース出力　&title + "を実行開始しました"

    　条件　( &trace )　トレース出力　_#日時値, "　 ", _[日付], "　 ", _#日数加算(#日時値, 7 )
    　条件　( &trace )　トレース出力　_#日時日付(#日時値), "　 ", _#日時日付([日付]), "　 ", #日時日付( #日数加算(#日時値, 7 ) )
    　条件　( &trace )　トレース出力　_( #日時日付(#日時値) <= #日時日付([日付]) )
    　条件　( &trace )　トレース出力　_( #日時日付([日付]) <= #日時日付( #日数加算(#日時値, 7 ) ) )
    　条件　( &trace )　トレース出力　_( #日時日付(#日時値) <= #日時日付([日付]) <= #日時日付( #日時値 ) )
    　条件　( &trace )　トレース出力　_( #日時日付(#日時値) <= #日時日付([日付]) <= #日時日付( #日数加算(#日時値, 7 ) ) )

    　条件　( &trace )　トレース出力　&title + "を実行終了しました"
    手続き定義終了

    ■トレース出力
    　　　　:cmdTestClick( )を実行開始しました
    　　　　:#日時値 : 2024年 6月18日 16時33分21.02秒　 [日付] : 2024年 6月25日　0時 0分 0秒　 #日数加算(#日時値, 7 ) : 2024年 6月25日 16時33分21.02秒
    　　　　:#日時日付(#日時値) : 2024年 6月18日　0時 0分 0秒　 #日時日付([日付]) : 2024年 6月25日　0時 0分 0秒　 2024年 6月25日　0時 0分 0秒
    　　　　:( #日時日付(#日時値) <= #日時日付([日付]) ) : 1
    　　　　:( #日時日付([日付]) <= #日時日付( #日数加算(#日時値, 7 ) ) ) : 1
    エラー　:KU1094:データの型が一致していません(D:\kiri10s\1718608933\スケジュール管理2\スケジュール表_main.kex　77行目)

    エラーになったのは、次のコマンドです

    　条件　( &trace )　トレース出力　_( #日時日付(#日時値) <= #日時日付([日付]) <= #日時日付( #日時値 ) )

    たぶんですが、


    　#日時日付(#日時値) <= #日時日付([日付])　<= #日時日付([日付])
    　・・・・・・・・・・・・・・・・・・・
    　　　　　　　　　↑
    　この部分の評価は整数の１（イチ：真）です

    次に右辺を比較すると

    　1 <= #日時日付([日付])

    １（イチ）と日時型の式（ #日時日付([日付])を比較したので、:KU1094:データの型が一致していません となった！。

    もちろん当方の推測ですけれど、だいたいそんなところでしょうね。


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

▲[ 1456 ] / ▼[ 1458 ]
■1457 / 12階層) 　Re[12]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/18(Tue) 17:05:22)
    2024/06/18(Tue) 23:55:23 編集(投稿者)

    ［桐 - ヘルプ］→［データと式］→［比較式］→［日時の検索］→［範囲で検索する］を参照すると

    　日時の範囲が「2014年10月1日」～「2015年4月20日」のレコードを検索します。
    　 d"2014/10/1"<=[]<d"2015/4/21"
    　　または
    　 >=d"2014/10/1",<d"2015/4/21"

    とあります。

    そこで、

    【変更前】expression1 <= val <= expression2

    　オブジェクト名： cmdStartUp
    　標題　　　　　： StartUp

    　　機能名　　　　　　機能パラメータリスト
    　1 表示
    　2 絞り込み_比較式　 #日時日付(#日時値) <= #日時日付([日付]) <= #日時日付( #日数加算(#日時値, 7 ) )
    　3 並べ替え_昇順　　 [日付]
    　4 訂正　　　　　　　 "txt日付_入力用"


    【変更後】expression1 <= val, val <= expression2

    　オブジェクト名： cmdStartUp
    　標題　　　　　： StartUp

    　　機能名　　　　　　機能パラメータリスト
    　1 解除　　　　　　 ＊
    　2 絞り込み_比較式　 #日時日付(#日時値) <= #日時日付([日付]), #日時日付([日付]) <= #日時日付( #日数加算(#日時値, 7 ) )
    　3 並べ替え_昇順　　 [日付]
    　4 訂正　　　　　　 "txt日付_入力用"

    とすると、エラーしなくなりました。

    もちろん、これはコマンドボタンの機能パラメータのエラー対策ということですよ。

    コマンドボタンの機能パラメータで使用する場合にだけ注意してください。





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

▲[ 1457 ] / ▼[ 1459 ]
■1458 / 13階層) 　Re[13]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ジェダイの桐 -(2024/06/19(Wed) 10:53:31)
    ONnojiさん


    > 　日時の範囲が「2014年10月1日」～「2015年4月20日」のレコードを検索します。
    > 　 d"2014/10/1"<=[]<d"2015/4/21"
    > 　　または
    > 　 >=d"2014/10/1",<d"2015/4/21"
    >
    > とあります。

    > 【変更前】expression1 <= val <= expression2

    > 　2 絞り込み_比較式　 #日時日付(#日時値) <= #日時日付([日付]) <= #日時日付( #日数加算(#日時値, 7 ) )
    >
    > 【変更後】expression1 <= val, val <= expression2

    > 　2 絞り込み_比較式　 #日時日付(#日時値) <= #日時日付([日付]), #日時日付([日付]) <= #日時日付( #日数加算(#日時値, 7 ) )


    > とすると、エラーしなくなりました。


    添削ありがとうございますm(__)m
    エラーが無くなりました。

    どうやったらエラーが無くなるか、実は試行錯誤していました。
    とは言え、求めたい結果が出ている、比較式で絞り込んでも　求めたい答えが出る・・・

    と苦慮していました。


    >　#日時日付(#日時値) <= #日時日付([日付])　<= #日時日付([日付])
    >　・・・・・・・・・・・・・・・・・・・
    　　　　　　　　　↑
    >　この部分の評価は整数の１（イチ：真）です

    >次に右辺を比較すると

    >　1 <= #日時日付([日付])

    >１（イチ）と日時型の式（ #日時日付([日付])を比較したので、:KU1094:データの型が一致していません となった！。

    >もちろん当方の推測ですけれど、だいたいそんなところでしょうね。

    の解説と


    expression1 <= val, val <= expression2
    >=d"2014/10/1",<d"2015/4/21"

    の対応策　解説があることで、意味が理解出来ました。


    ■14350　期間絞込でのエラー時対応について　の中の
    ■14369　モジュール化はフォームのレベルでも必要　の時の様に
    分かってしまえばあっけないのですが、理解するまでが時間がかかります。


    ある程度自分で考えて色々やった上で解説があると、理解度が増します。


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


    客観的に考えると、＜改良案２＞　の方が素直に感じました。
    まだまだ私は考え方が甘いです(T_T)


    ｐ.ｓ.

    サンプル開発に時間を割いて頂き、ありがとうございますm(__)m


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

▲[ 1458 ] / 返信無し
■1459 / 14階層) 　Re[14]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/19(Wed) 11:28:49)
    2024/06/19(Wed) 11:35:21 編集(投稿者)

    > 添削ありがとうございますm(__)m
    > エラーが無くなりました。
    > どうやったらエラーが無くなるか、実は試行錯誤していました。
    > とは言え、求めたい結果が出ている、比較式で絞り込んでも　求めたい答えが出る・・・
    > と苦慮していました。

    そうですか、お気づきでしたか？

    > の対応策　解説があることで、意味が理解出来ました。

    これは個人の好みの問題ですが・・・、

    私( ONnoji )は、expression1 <= val <= expression2 という比較式は一切使わないのです。

    もちろん、あくまでも個人の好みですから気にしないでください。(^^ゞ

    > ■14350　期間絞込でのエラー時対応について　の中の
    > ■14369　モジュール化はフォームのレベルでも必要　の時の様に
    > 分かってしまえばあっけないのですが、理解するまでが時間がかかります。

    コマンドボタンの機能パラメータリストの時だけの問題ですね。

    忘却していますが、ずいぶん昔に同じ話題を掲示板で調べたような記憶があります。

    > ある程度自分で考えて色々やった上で解説があると、理解度が増します。
    > 客観的に考えると、＜改良案２＞　の方が素直に感じました。
    > まだまだ私は考え方が甘いです(T_T)

    桐の「フォーム＋イベント処理」のプログラミングを始めたばかりなのですからねぇ～。

    そう簡単に上級者になれるハズがありませんよ。

    焦りは禁物です。

    コツコツ努力すれば必ず報われますよ。

    ｐ．ｓ．

    さて、サンプルはほぼ出来上がりました。

    しかし、内容が初級者レベルではありませんので、解説を用意します。

    なお先に申し上げておきますが、今回のサンプルは私( ONnoji )の好奇心で作ったものです。

    従って、こうすると良いよという提案ではありません。

    「こんなことも出来るんだけどね・・・でもそこまでする必要ないでしょ」という代物ですよ。

    どちらかというと、［トレース出力］コマンドを使ったデバッグの実習という感じでご覧ください。

    サンプルは午後にアップする予定です。


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

▲[ 1445 ] / ▼[ 1461 ] ▼[ 1462 ] ▼[ 1463 ] ▼[ 1467 ]
■1460 / 1階層) 　Re[1]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/19(Wed) 15:42:50)
    2024/06/19(Wed) 16:31:13 編集(投稿者)

    試してみれば分かりますが・・・

    編集対象表があるフォームは、表(.tbx)をフォーム(.wfx)でラップ（包む）したものですから、

    変数をソースにしたテキストボックスにキャレット（入力カーソル）を出現させると、

    表示モードから訂正モードや行挿入モードに遷移してしまいます。

    なので、NULLフォームとは勝手が違い戸惑いますよね。

    ということで、私( ONnoji )の場合ですが、

    編集対象表があるフォームのヘッダ部フッタ部に変数をソースにした編集可能なテキストボックスを基本的に作らないようにしています。
    　　　　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・・・・・・・・・

    それならばどうするのか？

    １．ポップアップ形式のダイアログボックスとしてのNULLフォームにデータを入力する


    　┌───────────────┐　　　ポップアップ
    　│編集対象があるフォーム　　　　│　　┌───────────────┐
    　│　　　　　　　　　　　　　　　│　　│NULLフォーム　　　　　　　　　│
    　│　　　　　　　　　　　　　　　├←─┤　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│　　│ダイアログボックス　　　　　　│
    　│　　　　　　　　　　　　　　　│　　└───────────────┘
    　│　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　└───────────────┘
    　※大量にデータを入力する使い方には向いていません

    ２．下側にデータエントリー用（NULLフォーム）のフォームを、上側に編集対象があるフォームをピッタリと上下に並べてにダイアログボックス側にデータを入力する

    　┌───────────────┐
    　│編集対象があるフォーム　　　　│
    　│　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　└──────┬────────┘
    　　　　　　［行追加］コマンド
    　┌──────┴────────┐
    　│NULLフォーム　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　│データエントリー用　　　　　　│
    　└───────────────┘
    　※上下でセットになっていますので、大量にデータを入力する使い方には向いています。

    が考えられます。

    私( ONnoji )は２．の方法のアプリケーションを数多く作っています。

    データエントリー用のフォームは汎用で１つだけ用意して、編集対象があるフォームを指定できる仕様にしてあります。

    　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇

    そしてこの度、３番めのアプローチに気が付いたのです。(^^ゞ

    それはメイン＆サブフォームという形式です。、

    　┌───────────────┐
    　│メインフォーム　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　│┌────────────┐　│
    　││サブフォーム　　　　　　│　│
    　││　　　　　　　　　　　　│　│
    　││　　NULLフォーム　　　　│　│
    　│└────────────┘　│
    　│　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　│編集対象があるフォーム　　　　│
    　│　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　│
    　└───────────────┘

    サンプルは出来上がりました。

    しかし、内容が初級者レベルではありませんので、↑このような解説を用意しました。

    なお先に申し上げておきますが、今回のサンプルは私( ONnoji )の好奇心で作ったものです。

    従って、こうすると良いよという提案ではありません。

    「こんなことも出来るんだけどね・・・でもそこまでする必要ないでしょ」という代物ですよ。

    どちらかというと、［トレース出力］コマンドを使ったデバッグの実習という感じでご覧ください。

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

▲[ 1460 ] / 返信無し
■1461 / 2階層) 　Re[2]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/19(Wed) 16:04:52)
    2024/06/19(Wed) 16:35:24 編集(投稿者)

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

    スケジュール表_main.kex
    スケジュール表_main.wfx
    スケジュール表_subform_accept.kex
    スケジュール表_subform_accept.wfx

    ※スケジュール表.TBX は含まれていません

    （ご注意）

    サブフォームからメインフォームへフォーカスを移動した場合には、
    サブフォームが表示モードになりますが、これは桐の仕様ですのでご了承ください。

    サブフォーム側をだけを操作している時には、訂正モードを維持します。
    ※実際には一時的に表示モードになりますけどね気が付かないと思います。(^^ゞ

    トレース出力を停止したい場合には、

    　&trace = 1

    を次のように

    　＊&trace = 1

    コメントアウトしてください。

    　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇

    以下は［トレース出力］コマンドの結果です。

    このような出力を得るには、［トレース出力］ウィンドウで、右クリックで［すべて選択］→［コピー］でクリップボードに保存してから、

    拙作の整形ユーティリティの［トレース整形］を実行して、［メモ帳を開く］ボタンを実行して、貼り付けてメモ帳を保存終了してください。

    自動的に整形が行われますよ。


    ┌when :main -> cmdStartupClick( )を実行開始しました
    │
    │　:この手続きは［開始時実行コマンド］ボタンから呼び出されました
    │
    │┌when :main -> cmd週間Click( )を実行開始しました
    │└end
    │
    │┌when :main -> prcサブフォームへフォーカスを移動( )を実行開始しました
    ││
    ││　:subform -> txt日付_入力用 のフォーカス設定()メソッドを実行します
    ││　:メソッドの実行結果
    ││　:&return : 1　 メソッド呼び出し　戻り値 = &return, @subformAccept.@txt日付_入力用.フォーカス設定()
    ││　:
    ││　:subform -> cmd訂正 の実行()メソッドを実行します
    ││　:メソッドの実行結果
    ││　:&return : 0　 メソッド呼び出し　戻り値 = &return, @subformAccept.@cmd訂正.実行()
    ││　:&mCommanButtonDone : 1　 &mCommanButtonDone が 1 になればＯＫ　何故かサブフォームでは &return が ゼロで返ってくる事がある
    ││
    │└end
    │
    └end

    ┌when :subform -> cmd予定追加Click( )を実行開始しました
    │
    │　:main -> フォーム に cmd行追加 が存在するか否かを調べるためにオブジェクト検査()メソッドを実行します
    │　:メソッドの実行結果
    │　:&isObject : 1　 &objectName : cmd行追加　メソッド呼び出し　ハンドル = &hwindow, 戻り値 = &return, @フォーム.オブジェクト検査( &objectName, &isObject )
    │　:
    │　:入力エラーを判定します　&error日付 = ( &m日付 = #u )　&error予定 = ( #trim( &m予定, 4 ) = #u )　&logical　 = .not ( &error日付 .or &error予定 )
    │　:&error日付 : 0　 &error予定 : 0　 &logical : 1
    │　:
    │　:main -> cmd行追加 の実行()メソッドを実行します
    │
    │┌when :main -> cmd行追加Click( )を実行開始しました
    ││
    ││　:&m日付 : 2024年 6月23日　0時 0分 0秒　 &m予定 : てすとです
    ││　:&status : 1　 行追加　 終了状態 = &status, [日付] = &m日付, [予定] = &m予定
    ││　:
    ││　:ここで prcサブフォームへフォーカスを移動( ) を実行するとサブフォームのフォーカスの移動が上手くいかない事がある
    ││　:回避策として、時限タイマーの［タイマー1］イベントをインターバル 20/100秒で予約して、プログラムの流れを中断する
    ││　:オブジェクト操作　@フォーム｛ タイマー1 = 1, タイマー値1 = 20 ｝
    ││
    │└end
    │
    │　:メソッドの実行結果
    │　:&return : 1　 &objectName : cmd行追加　メソッド呼び出し　ハンドル = &hwindow, 戻り値 = &return, &objectName.実行()
    │
    └end

    ┌when :main -> フォーム::タイマー1( )を実行開始しました
    │
    │　:時限タイマーの［タイマー1］イベントを停止
    │　:オブジェクト操作　@フォーム｛ タイマー1 = 0 ｝　/* 時限タイマーの［タイマー1］イベントを停止 */
    │　:
    │　:cmd行追加Click( )で中断したプログラムの流れをここから再開する
    │　:　↓
    │　:手続き実行　prcサブフォームへフォーカスを移動( )
    │
    │┌when :main -> prcサブフォームへフォーカスを移動( )を実行開始しました
    ││
    ││　:subform -> txt日付_入力用 のフォーカス設定()メソッドを実行します
    ││　:メソッドの実行結果
    ││　:&return : 1　 メソッド呼び出し　戻り値 = &return, @subformAccept.@txt日付_入力用.フォーカス設定()
    ││　:
    ││　:subform -> cmd訂正 の実行()メソッドを実行します
    ││　:メソッドの実行結果
    ││　:&return : 0　 メソッド呼び出し　戻り値 = &return, @subformAccept.@cmd訂正.実行()
    ││　:&mCommanButtonDone : 1　 &mCommanButtonDone が 1 になればＯＫ　何故かサブフォームでは &return が ゼロで返ってくる事がある
    ││
    │└end
    │
    └end

    ｐ．ｓ．

    > なお先に申し上げておきますが、今回のサンプルは私( ONnoji )の好奇心で作ったものです。
    > 従って、こうすると良いよという提案ではありません。
    > 「こんなことも出来るんだけどね・・・でもそこまでする必要ないでしょ」という代物ですよ。

    これは個人の感想です。(^^ゞ

    メイン＆サブフォームを好んで使う人もいますが、私はメイン＆サブフォームはもうコリゴリなので避けています。

    しかし、今回は面白いテーマだったので試してみました。(^^ゞ

    なぜもうコリゴリなのかと言うと・・・

    ・メインの局所変数がサブで上書きされる事　※メインとサブの局所変数のスコープは共通ですから当然ですけど(^^ゞ

    ・デバッグが非常にし難い事

    ・拙作：フレームワークがサブフォームに適用できない事　※初期はサブフォームにも対応していましたが、デバッグと変数のスワップが大変なので止めました。

    ですね。


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

▲[ 1460 ] / 返信無し
■1462 / 2階層) 　Re[2]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ジェダイの桐 -(2024/06/19(Wed) 17:02:33)
    ONnojiさん


    こんにちは！

    サンプルありがとうございますm(__)m

    本日は、所用がありますので明日熟読し、返信させて頂きます。
[ 親 1445 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 1460 ] / ▼[ 1464 ]
■1463 / 2階層) 　Re[2]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ 尾形 -(2024/06/19(Wed) 18:06:28)
    どうも、こんにちは

    ガンチャートに興味があったので
    拝見してました


    > 変数をソースにしたテキストボックスにキャレット（入力カーソル）を出現させ>
    > 表示モードから訂正モードや行挿入モードに遷移してしまいます。

    わたしも困ってたので、色々探しました

    変数(ファミリ)のフォーカス取得イベントで
    オブジェクト操作　@フォーム.訂正モード = "0"

    で多分いいかと思います

    流し読みなので、違ってたらすいません

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

▲[ 1463 ] / 返信無し
■1464 / 3階層) 　Re[3]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/19(Wed) 19:11:08)
    2024/06/19(Wed) 19:27:10 編集(投稿者)

    尾形さん

    >>変数をソースにしたテキストボックスにキャレット（入力カーソル）を出現させ>
    >>表示モードから訂正モードや行挿入モードに遷移してしまいます。
    > わたしも困ってたので、色々探しました
    > 変数(ファミリ)のフォーカス取得イベントで
    > オブジェクト操作　@フォーム.訂正モード = "0"

    なるほどですね。(^^v

    ［名札　メイン］で次のように指定してもＯＫですね。

    　オブジェクト操作　@フォーム｛ 行訂正 = 0, 行挿入 = 0, 行削除 = 0, 行復活 = 0 ｝

    　　または

    　オブジェクト操作　@フォーム｛ 行訂正 = "0", 行挿入 = "0", 行削除 = "0", 行復活 = "0" ｝

    ↑
    これらの属性は［オブジェクトのリスト］ウィンドウの［フォーム］オブジェクトの［許可作業］タブにあります。

    添付画像を参照。

    フォーカスによってオン／オフをするというのも一つの方法ですね。

    ｐ．ｓ．

    詳しく調べていませんが・・・(^^ゞ

    ヘッダ部・フッタ部に［変数がソースのテキスト］があったとして、

    明細部のレコードの［項目名がソースのテキスト］と［変数がソースのテキスト］を往来する場合には、

    モードの管理がちょっとややこしくなるかもしれませんね。

662×348 => 250×131

1718792137.jpg/57KB
[ 親 1445 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 1460 ] / ▼[ 1468 ]
■1467 / 2階層) 　Re[2]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ジェダイの桐 -(2024/06/20(Thu) 14:50:53)
    ONnojiさん


    こんにちは！


    本日は、ずっとトレース出力ウィンドウ　と　スケジュール表_main.kex　と　スケジュール表_subform_accept.kex　とにらめっこしています。


    率直な感想


    1、私の思い描いた通りに動いている
    2、メイン　サブ　間のフォーカス移動は相当大変
    3、サブ　→　メイン　に行訂正も相当大変


    取り入れるべき事


    間違いなく、トレース出力　の使い方です。
    kexのプログラム文章　と　実際に入力してみて　をトレース出力ウィンドウで見ていて小説を読んでいる様に感じました。


    どういう理屈のプログラムなのかという事は表面的にしか分かりません。
    しかし、プログラムの流れはしっかりと分かります。


    変数に入っている値が何か、プログラムの動きがどうか理解しながら作成すると言う、あるべき姿を見せて頂いたと思っております。


    トレース出力は便利と言うより、必須に近いと感じています。
    （但し、分かりやすい事が条件ですが。）


    なので今後、自分で作成するプログラムは、こちらのトレース出力方法を参考にさせて頂きますm(__)m


    分からないなりに推測した事


    このプログラムのピタゴラスイッチは
    &mCommanButtonDone　なのではないかと推測しました。


    初期値には　0　が入っていて　
    サブフォームの　cmd訂正　をメソッドで実行した時
    機能名1　#代入( &mCommanButtonDone, 1 )になる。


    これが起点になっているのかな？と推測しました。


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


    本来であれば、一番素直な方法は編集対象表があるので直接入力でした。
    （冗談抜きでONnojiさんに言われるまで、発想が全く出てきませんでした・・・）


    それでも入力フォームを用意する場合、
    私はそこまで予定を入力する事を想定していなかったので、NULLフォームで


    > １．ポップアップ形式のダイアログボックスとしてのNULLフォームにデータを入力する
    >
    >
    > 　┌───────────────┐　　　ポップアップ
    > 　│編集対象があるフォーム　　　　│　　┌───────────────┐
    > 　│　　　　　　　　　　　　　　　│　　│NULLフォーム　　　　　　　　　│
    > 　│　　　　　　　　　　　　　　　├←─┤　　　　　　　　　　　　　　　│
    > 　│　　　　　　　　　　　　　　　│　　│ダイアログボックス　　　　　　│
    > 　│　　　　　　　　　　　　　　　│　　└───────────────┘
    > 　│　　　　　　　　　　　　　　　│
    > 　│　　　　　　　　　　　　　　　│
    > 　│　　　　　　　　　　　　　　　│
    > 　│　　　　　　　　　　　　　　　│
    > 　└───────────────┘
    > 　※大量にデータを入力する使い方には向いていません


    こちらの１．の方法が適切だったと言う事が分かりました。


    > ２．下側にデータエントリー用（NULLフォーム）のフォームを、上側に編集対象があるフォームをピッタリと上下に並べてにダイアログボックス側にデータを入力する
    >
    > 　┌───────────────┐
    > 　│編集対象があるフォーム　　　　│
    > 　│　　　　　　　　　　　　　　　│
    > 　│　　　　　　　　　　　　　　　│
    > 　│　　　　　　　　　　　　　　　│
    > 　│　　　　　　　　　　　　　　　│
    > 　│　　　　　　　　　　　　　　　│
    > 　│　　　　　　　　　　　　　　　│
    > 　│　　　　　　　　　　　　　　　│
    > 　└──────┬────────┘
    > 　　　　　　［行追加］コマンド
    > 　┌──────┴────────┐
    > 　│NULLフォーム　　　　　　　　　│
    > 　│　　　　　　　　　　　　　　　│
    > 　│データエントリー用　　　　　　│
    > 　└───────────────┘
    > 　※上下でセットになっていますので、大量にデータを入力する使い方には向いています。


    もし今後、大量データ入力が必要になった時は、２．の方法で検討します。


    ｐ.ｓ.


    > どちらかというと、［トレース出力］コマンドを使ったデバッグの実習という感じでご覧ください。


    正にデバック実習状態になりましたが、　トレース出力　の凄さを実感出来た事が大収穫です(^^♪


    本当にありがとうございましたm(__)m


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

▲[ 1467 ] / ▼[ 1469 ]
■1468 / 3階層) 　Re[3]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/20(Thu) 16:14:46)
    2024/06/20(Thu) 23:21:13 編集(投稿者)

    > 本日は、ずっとトレース出力ウィンドウ　と　スケジュール表_main.kex　と　スケジュール表_subform_accept.kex　とにらめっこしています。
    > 率直な感想
    > 1、私の思い描いた通りに動いている
    > 2、メイン　サブ　間のフォーカス移動は相当大変
    > 3、サブ　→　メイン　に行訂正も相当大変
    > 取り入れるべき事
    > 間違いなく、トレース出力　の使い方です。
    > kexのプログラム文章　と　実際に入力してみて　をトレース出力ウィンドウで見ていて小説を読んでいる様に感じました。
    > どういう理屈のプログラムなのかという事は表面的にしか分かりません。
    > しかし、プログラムの流れはしっかりと分かります。
    > 変数に入っている値が何か、プログラムの動きがどうか理解しながら作成すると言う、あるべき姿を見せて頂いたと思っております。

    「目からウロコ」の第９項で

    　「このソフトウェアという言葉を、［柔らかな機械］と考えていただきたいのです。
    　　見えなくて、実際に触ることも出来ないけれど、それは機械と同じなんだとね。(*^^)ok」

    このように書きました。

    今回のメイン＆サブフォームのピタゴラ装置も［柔らかな機械］の動作なのです。

    だから、実際にどう動いているのか？を一つ一つ確かめないと、ピタゴラ装置が途中で止まってしまうかもしれないのです！

    ということで、単に変数の値を調べるだけではなく、

    見えない動作を、見える化するのが、［トレース出力］コマンドのもう一つの使い方になります。

    > トレース出力は便利と言うより、必須に近いと感じています。
    > （但し、分かりやすい事が条件ですが。）
    > なので今後、自分で作成するプログラムは、こちらのトレース出力方法を参考にさせて頂きますm(__)m

    今回のアプリケーションは挙動（動作）が複雑です。

    だから、本腰を入れてデバッグ用の［トレース出力］コマンドを満載しました。

    しかし、普通の場合には、今回のような非常に複雑なピタゴラ装置にはなりませんよね。

    なので、ここまで徹底的な準備は必要無いですよ。

    しかし、どうしても期待どうりの挙動が得られない場合には、今回の内容を思い出してデバッグしてみてください。

    > 分からないなりに推測した事
    > このプログラムのピタゴラスイッチは
    > &mCommanButtonDone　なのではないかと推測しました。
    > 初期値には　0　が入っていて　
    > サブフォームの　cmd訂正　をメソッドで実行した時
    > 機能名1　#代入( &mCommanButtonDone, 1 )になる。
    > これが起点になっているのかな？と推測しました。

    コマンドボタンの［実行］メソッドですが、

    　　&mCommanButtonDone = 0
    　　メソッド呼び出し　戻り値 = &return, @subformAccept.@cmd訂正.実行()　/* &mCommanButtonDone が 1 になればＯＫ　何故かサブフォームでは &return が ゼロで返ってくる事がある */
    　　**戻り値　意味
    　　** 1　　　正常終了
    　　**1以外　 実行できない、またはエラーで終了した

    　　**＜参考＞
    　　**スケジュール表_subform_accept.wfx
    　　**　オブジェクト名： cmd訂正
    　　**　標題　　　　　： cmd訂正：予約済み　削除不可
    　　**　　機能名　機能パラメータリスト
    　　**　1 なし　　#代入( &mCommanButtonDone, 1 )　　※&mCommanButtonDone が 1 になればＯＫ
    　　**　2 訂正
    　　**　3 なし
    　　**　4 なし

    論より証拠です。

    実際に［実行］メソッドによって、コマンドボタンが実行されているにも関わらず 戻り値 = &return の値がゼロです。

    ※これはメインフォームからサブフォームのコマンドボタンを実行した場合に限るようですが・・・

    桐のプログラミングを長年やっていると、こういう些細なことに遭遇するものなのですよ。

    だから、私( ONnoji )はずいぶん昔からこのアプローチを採用しています。※拙作フレームワークのランチャー等

    > これが起点になっているのかな？と推測しました。

    今回は単に動作を確認するためだけに &mCommanButtonDone を使っただけです。

    しかし、もしもメソッドを実行した後で
    　　　　・・・・・・・・・・・・・

    　if ( &return = 1 )

    と判定する必要があったならば、誤った判定によってピタゴラ装置の動作が変になりますよね。
    　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    ということで、 ※ ちなみに &mCommanButtonDone は &mCommandButtonDone と書いたつもりでしたが、"d" を打ち忘れましたね。(^^ゞ

    　if ( &mCommanButtonDone )　/* 0 or 1 */

    という具合に、「石橋を叩いて渡る」というアプローチをしているのです。

    ちなみに、この↓メソッド

    　　メソッド呼び出し　戻り値 = &return, @subformAccept.@cmd訂正.実行()

    は、サブフォーム側のコマンドボタン：cmd訂正 を実行しているだけですよ。

    > 本来であれば、一番素直な方法は編集対象表があるので直接入力でした。
    > （冗談抜きでONnojiさんに言われるまで、発想が全く出てきませんでした・・・）

    通常の場合には、直接入力で十分ですよ。

    しかし、エラーを厳密にチェックしたい場合には、補助フォームを使う方がよいと思いますよ。

    >>どちらかというと、［トレース出力］コマンドを使ったデバッグの実習という感じでご覧ください。
    > 正にデバック実習状態になりましたが、　トレース出力　の凄さを実感出来た事が大収穫です(^^♪

    ［トレース出力］コマンドは、［トレース出力］ウィンドウの生のデータを見ただけでは、超ワカリニクイですよね。

    なので、拙作：整形ユーティリティの［トレース整形］機能を使ってください。

    ｐ．ｓ．

    今回は、"main ->" と "subform ->" で、フォームの区別を明確にしています。

    しかし、このようにするのは面倒です。

    なので、拙作：フレームワークのデバッグの場合には、

    ┌when :INF_FW_IPS_Master.wfx hdl= 2>EZWprcEventRecMoveRun( )を実行開始しました
    │
    │　:INF_FW_IPS_Master.wfx hdl= 2>EZWprcEventRecMoveRun( ) 引数：長整数　&行番号 = 15
    │　:INF_FW_IPS_Master.wfx hdl= 2>EZWprcEventRecMoveRun( ) &EZWmRecFocus　　　　 = 14
    │　:INF_FW_IPS_Master.wfx hdl= 2>EZWprcEventRecMoveRun( ) &EZWmRecNow　　　　　 = 15
    │
    └end

    　または

    ┌when :D:\〇×△\INF_FW_IPS_Master.wfx hdl= 2>EZWprcEventRecMoveRun( )を実行開始しました
    │
    │　:D:\〇×△\INF_FW_IPS_Master.wfx hdl= 2>EZWprcEventRecMoveRun( ) 引数：長整数　&行番号 = 16
    │　:D:\〇×△\INF_FW_IPS_Master.wfx hdl= 2>EZWprcEventRecMoveRun( ) &EZWmRecFocus　　　　 = 15
    │　:D:\〇×△\INF_FW_IPS_Master.wfx hdl= 2>EZWprcEventRecMoveRun( ) &EZWmRecNow　　　　　 = 16
    │
    └end

    このように、ファイル名 ＋ ハンドル番号 または ドライブ＋パス＋ファイル名 ＋ ハンドル番号 付きでトレース出来るようにしてあります。

    例えば、主フォームと補助フォームが連動して動く場合のように、複数のフォームの挙動をトレースするためには、このような工夫も必要になってきます。

    もちろん、ただひとつのフォームを使用している時のトレースの場合にはこのような工夫は必要無いですよ。アハハハha


    ｐ．ｐ．ｓ．

    そうそう、時限式タイマーが出てきて驚いたことでしょう。

    手続き定義開始　cmd行追加Click( )
    　　：
    　　：
    　** ここで prcサブフォームへフォーカスを移動( ) を実行するとサブフォームのフォーカスの移動が上手くいかない事がある
    　** サブフォームのコマンドボタン：cmd予定追加 をマウス左クリック以外で実行した場合には、　txt日付_入力用 にフォーカスが移動する　：Ｇｏｏｄ
    　** サブフォームのコマンドボタン：cmd予定追加 をマウス左クリックした時だけ、サブフォームのtxt日付_入力用 にフォーカスが移動しない：ＮＧ
    　** ＮＧ：手続き実行　prcサブフォームへフォーカスを移動( )
    　** 回避策として、時限タイマーの［タイマー1］イベントをインターバル 50/100秒で予約して、プログラムの流れを中断する

    という説明の通りです。

    非常にまれですが、「どうしても具合が悪い場合」に遭遇する事があるものです。

    その時には、プログラムの流れを終わらせて、時限式タイマーで続きを実行するというアプローチで解決することが多いです。

    もちろん、普通の場合には「どうしても具合が悪い場合」に遭遇する事はありませんから、過度な心配は要りませんよ。

    ｐ．ｐ．ｐ．ｓ．

    > 本日は、ずっとトレース出力ウィンドウ　と　スケジュール表_main.kex　と　スケジュール表_subform_accept.kex　とにらめっこしています。

    そうそう、トレース出力ウィンドウとにらめっこするよりは、

    一通り動かして出力結果をクリップボードにコピーして、整形ユーティリティで整形したものを、
    ・・・・・・・・・・・・・・・・・・・・・・・

    ｛ 画面で見る・ファイルに出力する・印刷する ｝方が落ち着いて見られますよ。


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

▲[ 1468 ] / ▼[ 1470 ]
■1469 / 4階層) 　Re[4]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/21(Fri) 00:40:47)
    2024/06/21(Fri) 08:52:55 編集(投稿者)
    2024/06/21(Fri) 01:05:02 編集(投稿者)

    ジェダイの桐さん

    作ったけれど使っていないファミリ、未使用のオブジェクト、ワークスペースに移動した旧オブジェクトなど

    整理されていない部分がありましたので、

    全体を見渡すダイアグラム（図）を描いてみました。

    特にメソッドを実行するオブジェクトには、●★〇☆１☆２のマークを付けました。

    これで少しは迷子にならないで済むかもしれません。アハハha

    なお、オブジェクトのリストは拙作整形ユーティリティの［フォーム定義リスト］で作図しています。

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

    　スケジュール表_main.wfx　　　　　　　　　　　　　　　　　　　　　スケジュール表_subform_accept.wfx
    　フォーム　●オブジェクト検査()　　　　　　　　　　　　　　　　　 フォーム
    　│　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　│
    　├ ファミリ　　　　　　　　　　　　　　　　　　　　　　　　　　　 ├ ファミリ
    　│　└ famButton 　　　　　未使用　※作ったが使っていない　　　　 ├ ワークスペース
    　├ ワークスペース　　　　　　　　　　　　　　　　　　　　　　　　 │　└ cmd訂正　〇実行()
    　│　├ XcmdStartUp　　　　 未使用　旧開始時実行コマンド　　　　　 │
    　│　├ txt日付_入力用　　　未使用　明細部から移動しただけ　　　　 │
    　│　│　└ lbl日付_入力用　　↑　　　　　　　　　　　　　　　　　 ├ フォームヘッダ部　※このセクションは未使用なので非表示です
    　│　├ txt予定_入力用　　　　；　　　　　　　　　　　　　　　　　 │　└ lbl説明
    　│　│　└ lbl予定_入力用　　↓　　　　　　　　　　　　　　　　　 │
    　│　├ cmd予定追加 　　　　未使用　明細部から移動しただけ 　　　　│
    　│　│　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　│
    　│　├ cmdStartup 　　開始時実行コマンド：予約済み　削除不可　　　│
    　│　│　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　│
    　│　├ cmd行追加　★実行()　予約済み　削除不可　　　　　　　　　　│
    　│　│　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　│
    　│　└ cmdTest　　　　　　　未使用　テスト用　 　　　　　　　　　 │
    　│　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　│
    　│↑ここより上のオブジェクトは表示されていません　　　　　　　　　│↑ここより上のオブジェクトは表示されていません
    　│　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　│
    　├ フォームヘッダ部　　 　　　　　　　　　　　　　　　　　　　　　│
    　│　├ subformAccept　サブフォームオブジェクト　→→→→→→→→→└ フォーム明細部
    　│　├ lbl日付　　　　　　　　　　　　　　　　　　　　　　　　　　　　├ txt日付_入力用　☆１フォーカス設定()
    　│　├ cmd当日　　　　　　　　　　　　　　　　　　　　　　　　　　　　├ txt予定_入力用　☆２フォーカス設定()
    　│　├ lbl予定　　　　 　　　　　　　　　　　　　　　　　　　　　　　 └ cmd予定追加
    　│　├ cmd週間
    　│　├ cmd絞込_式　　　　　　　　　　　　　　　　　　　　　　　　　&objectName = "cmd行追加"
    　│　├ cmd絞込_値　　　　　　　　　　　　　　　　●　メソッド呼び出し　ハンドル = &hwindow, 戻り値 = &return, @フォーム.オブジェクト検査( &objectName, &isObject )
    　│　├ cmd前週　　　　　　　　　　　　　　　　　　　　　　　　 ★　メソッド呼び出し　ハンドル = &hwindow, 戻り値 = &return, &objectName.実行()
    　│　├ cmd次週
    　│　├ cmd今月　　　　　　　　　　　　　　　　　　　　　　　 ☆１　&objectName = "txt日付_入力用"
    　│　├ cmd前月　　　　　　　　　　　　　　　　　　　　　　　 ☆２　&objectName = "txt予定_入力用"
    　│　├ cmd次月　　　　　　　　　　　　　　　　　　　　　 ☆１☆２　メソッド呼び出し　戻り値 = &return, &objectName.フォーカス設定()
    　│　├ lbl日付_入力用_1　項目のラベル
    　│　└ lbl予定_入力用_1　項目のラベル　　　　　　　　　　　　　〇　メソッド呼び出し　戻り値 = &return, @cmd訂正.実行()
    　└ フォーム明細部
    　　　├ 行セレクタ
    　　　├ txt日付 　　　　　表の項目
    　　　└ txt予定 　　　　　表の項目

    　☆１　メソッド呼び出し　戻り値 = &return, @subformAccept.@txt日付_入力用.フォーカス設定()
    　〇　　メソッド呼び出し　戻り値 = &return, @subformAccept.@cmd訂正.実行()

    ｐ．ｓ．

    この程度の図でも書いておかないと、後日「フォーム＋イベント処理」を見た時にさっぱり分からなくなるんですよ。

    自分で作ったアプリケーションにも関わらず、後日内容を理解するのに何時間も格闘するのはつまらないでしょう。(^^ゞ

    もちろん、とてもシンプルな「フォーム＋イベント処理」ならば図を書かなくても済みますよ。アハハハha

    ｐ．ｐ．ｓ．

    > 作ったけれど使っていないファミリ、未使用のオブジェクト、ワークスペースに移動した旧オブジェクトなど

    思い出しました。(^^ゞ

    ファミリ：famButton は、イベントハンドラの為に作ったのではありませんでした。

    これは、フォーム定義中に一時的にオブジェクトを非表示にするために使ったのでした。(^^ok

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

▲[ 1469 ] / ▼[ 1471 ]
■1470 / 5階層) 　Re[5]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/21(Fri) 09:27:40)
    2024/06/21(Fri) 09:32:08 編集(投稿者)

    今回のメイン＆サブフォーム形式のアプリケーションでは

    メイン側　　　：１３個のプロシージャ（手続き）
    サブフォーム側：　３個のプロシージャ（手続き）

    を用意しました。

    　スケジュール表_main.kex

    　名札　　メイン
    　フォーム::タイマー1
    　cmdStartupClick
    　cmdTestClick　　← 一時的なテスト用
    　cmd行追加Click
    　cmd今月Click
    　cmd次月Click
    　cmd次週Click
    　cmd週間Click
    　cmd前月Click
    　cmd前週Click
    　INFprcMsgPause
    　prcサブフォームへフォーカスを移動

    　スケジュール表_subform_accept.kex

    　名札　　メイン
    　cmd予定追加Click
    　INFprcMsgPause


    上位プロシージャと下位プロシージャの関係は次の２つです。

    　スケジュール表_main.kex

    　cmdStartupClick
    　├ cmd週間Click
    　└ prcサブフォームへフォーカスを移動

    　フォーム::タイマー1
    　└ prcサブフォームへフォーカスを移動

    しかし、実際には

    　メソッド呼び出し　commandButtonName.実行()

    という飛び道具が使われているので、手続き実行の流れだけを追いかけても実際の動作を理解出来ません。

    この点が、分かり易さの邪魔をしているということですね。

    更に、追い打ちをかけるようにメイン＆サブフォームという仕掛け自体も、分かり易さの邪魔をしてますね。

    つまり、どれだけ分かり易くなるように工夫しても、それには限度があるということです。

    ｐ．ｓ．

    今回の例でも、［一般手続き］は多用しますが、［イベントハンドラ］は殆ど出番がありませんね。

    もしも、［イベントハンドラ］のオンパレードのイベント処理(.kex)の場合には、ひょっとしてアプローチがおかしいのではないか？と疑うことも大切ですよ。

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

▲[ 1470 ] / ▼[ 1473 ]
■1471 / 6階層) 　Re[6]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ジェダイの桐 -(2024/06/21(Fri) 15:23:30)
    2024/06/21(Fri) 15:47:54 編集(投稿者)
    2024/06/21(Fri) 15:46:18 編集(投稿者)
    2024/06/21(Fri) 15:24:13 編集(投稿者)

    ONnojiさん


    こんにちは！


    > 一通り動かして出力結果をクリップボードにコピーして、整形ユーティリティで整形したものを、
    > ・・・・・・・・・・・・・・・・・・・・・・・
    >
    > ｛ 画面で見る・ファイルに出力する・印刷する ｝方が落ち着いて見られますよ。


    実際に色々操作して、整形ユーティリティにコピペして見ました。


    感動しました。
    自分で作成したプログラムも、こちらにコピペしてみました。


    自分の思い通りに動いているのか・動いていないのかが可視化してくれるます。
    なので実現したいプログラムの進捗状況が分かるのが素晴らしいと感じました。



    > なお、オブジェクトのリストは拙作整形ユーティリティの［フォーム定義リスト］で作図しています。


    こちらも、整形ユーティリティを実際に使いました。


    頭を整理する時に、リスト図にしてくれるので非常に便利ですね！


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


    AKさんの推薦のことばに


    『これからイベント処理を勉強する方、既存のやり方に限界を感じている方にも十分推薦できるアプリ』


    と言う意味を少し垣間見ました。


    何故少しなのかと言えば、整形ユーティリティを使いこなせていないからです。


    もっと使用し、機能を使っていきたいと思います(^^♪


    ｐ.ｓ.


    > ｐ．ｐ．ｓ．
    >
    > そうそう、時限式タイマーが出てきて驚いたことでしょう。
    > 非常にまれですが、「どうしても具合が悪い場合」に遭遇する事があるものです。

    > その時には、プログラムの流れを終わらせて、時限式タイマーで続きを実行するというアプローチで解決することが多いです。


    この意味が分かる日が来るまで頑張ります(^^ゞ


    本当に本当に素人が感じた感想です。

    　・
    　・
    　・

    オブジェクト操作　@フォーム｛ タイマー1 = 1, タイマー値1 = 20 ｝

    　↓


    手続き定義終了


    タイマー1　でプログラムの流れを　中断　させた後　手続き定義終了　になっているので


    --------------------------------------------------------------------------------

    オブジェクト操作　@フォーム｛ タイマー1 = 1, タイマー値1 = 20 ｝
    以前

    --------------------------------------------------------------------------------

    オブジェクト操作　@フォーム｛ タイマー1 = 1, タイマー値1 = 20 ｝

    --------------------------------------------------------------------------------

    オブジェクト操作　@フォーム｛ タイマー1 = 1, タイマー値1 = 20 ｝
    以後

    --------------------------------------------------------------------------------


    手続き定義全体では１つの流れになっていると思います。


    なので、タイマー1で　流れを中断させなければならない状況とは、余程複雑な問題なのだろうと思いました(◎_◎;)


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

▲[ 1471 ] / ▼[ 1484 ]
■1473 / 7階層) 　Re[7]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/24(Mon) 22:03:36)
    2024/06/25(Tue) 13:27:03 編集(投稿者)
    2024/06/25(Tue) 00:22:15 編集(投稿者)

    >>そうそう、時限式タイマーが出てきて驚いたことでしょう。
    >>非常にまれですが、「どうしても具合が悪い場合」に遭遇する事があるものです。
    >>その時には、プログラムの流れを終わらせて、時限式タイマーで続きを実行するというアプローチで解決することが多いです。
    >
    > この意味が分かる日が来るまで頑張ります(^^ゞ
    > 本当に本当に素人が感じた感想です。
    >
    > オブジェクト操作　@フォーム｛ タイマー1 = 1, タイマー値1 = 20 ｝
    > 　↓
    > 手続き定義終了
    >
    > タイマー1　でプログラムの流れを　中断　させた後　手続き定義終了　になっているので
    > 手続き定義全体では１つの流れになっていると思います。

    ご明察です！、その通りですよ。(^^ok

    以下の・・・

    　 cmd行追加Click( )

    　　オブジェクト操作　@フォーム｛ タイマー1 = 1, タイマー値1 = 20 ｝

    　フォーム::タイマー1()

    　　オブジェクト操作　@フォーム｛ タイマー1 = 0 ｝　/* 時限タイマーの［タイマー1］イベントを停止 */
    　　手続き実行　prcサブフォームへフォーカスを移動( )

    を図解すると↓次のようになります。

    　　一般プロシージャ　　　　　　　　　　　　　　　　　　　　　 イベントプロシージャ
    　　cmd行追加Click( )　　　　　　　　　　　　　　　　　　　　　フォーム::タイマー1()
    　┌────────────────┐　　　　　　　　　　　　┌─────────────────────────┐
    　│　　　　　　　　　　　　　　　　│　　　　　　　　　　　　│フォーム::タイマー1() 　　　　　　　　　　　　　　│
    　│&objectName = "フォーム"　　　　│　　　　　　　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　│
    　│&interval　 = 10　　　　　　　　│　　　　　　　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　│
    　│　：　　　　　　　　　　　　　　│　　　　　　　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　│
    　│　：　　　　　　　　　　　　　　│cmd行追加Click( )が終了 │オブジェクト操作　@フォーム　　　　　　　　　　　 │
    　│　　　　　　　　　　　　　　　　│　した後のインターバル　│｛タイマー1 = 0 ｝　　　　　　　　　　　　　　　　│
    　│オブジェクト操作　@フォーム　 　│　　　↓　　　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　│
    　│｛タイマー1　 = 1， 　　　　　　│├─────┤イベントが│　* コマンドまたはメソッド　　　　　　　　　　　　│
    　│　タイマー値1 = 20 　　　 　｝　│　　時間差　　　発生　　│　手続き実行　prcサブフォームへフォーカスを移動( )│
    　│　　　　　　　　　　　　　　　　│　　　　　　　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　│
    　│　：　　　　　　　　　　　　　　│　　　　　　　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　│
    　│　：　　　　　　　　　　　　　　│　　　　　　　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　│
    　│　　　　　　　　　　　　　　　　│　　　　　　　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　│
    　└────────────────┘　　　　　　　　　　　　└─────────────────────────┘
    　　※［タイマーイベント］プロシージャの冒頭で、［イベント］属性をオフにする。つまり、［タイマー］イベントが発生しないようにする。

    この流れを見てみると・・・

    　　　手続き定義開始　cmd行追加Click( )

    　　　　行追加　 終了状態 = &status, [日付] = &m日付, [予定] = &m予定
    　　　　&m日付 = #u
    　　　　&m予定 = #u
    　　　　** ＮＧ：手続き実行　prcサブフォームへフォーカスを移動( )
    　　　　**　　　　　　↓
    　　　　**　　ＮＧのために一旦タイマー1 を予約して、タイマー1 で実行するようにした
    　　　　**　　　　　　↓
    　　　　オブジェクト操作　@フォーム｛ タイマー1 = 1, タイマー値1 = 20 ｝

    　　　手続き定義終了

    　　　手続き定義開始　フォーム::タイマー1()

    　　　　手続き実行　prcサブフォームへフォーカスを移動( )

    　　　手続き定義終了


    　　　手続き定義開始　prcサブフォームへフォーカスを移動( )

    　　　　メソッド呼び出し　戻り値 = &return, @subformAccept.@cmd訂正.実行()

    　　　手続き定義終了

    という３個のプロシージャが関係していますね。(^^ゞ

    　　cmd行追加Click　※このプロシージャから呼び出す手続きはありませんが・・・、タイマーは予約されています
    　　　；
    　　　；
    　　予約したインターバルは、 20/100秒です
    　　　；
    　　　；
    　　 20/100秒後にタイマー1 イベントが発生します！
    　　　；
    　　　；
    　　　└ フォーム::タイマー1
    　　　　　└ prcサブフォームへフォーカスを移動( )

    ↑上のように、

    　　cmd行追加Click() … インターバルで指定した秒数が経過するまで何もしない … タイマー1() → prcサブフォームへフォーカスを移動( )

    > 手続き定義全体では１つの流れになっていると思います。

    ということで、ご明察です。v(^^)v

    つまり、

    　　プロシージャＡ() … インターバルで指定した秒数が経過するまで何もしない … タイマー1() → プロシージャＢ()

    という風に覚えてください。

    タイマーに関しては拙作ｗｅｂページで解説していますので、ご参考にしてください。

    こちら
    　↓
    １１　［タイマー1/2］イベントの動的セット｜桐の釣魚大全のトップ > フォームアプリケーション教書　第１部
    http://silicon7565.html.xdomain.jp/guide/guide_Part1.htm#section11

    ｐ．ｓ．

    ［タイマー］イベントは、［ピタゴラ装置］で［時間経過によって作動する仕掛け］と全く同じですねぇ～。(^^ゞ

    やっぱり、［フォーム＋イベント処理］を［ピタゴラ装置］に例えると分かり易いですね。アハハハha


    ｐ．ｐ．ｓ．

    そもそもの話に戻せば・・・(^^ゞ

    以下は、手続き：cmd行追加Click( )内のコメント

    　** ここで prcサブフォームへフォーカスを移動( ) を実行するとサブフォームのフォーカスの移動が上手くいかない事がある
    　** サブフォームのコマンドボタン：cmd予定追加 をマウス左クリック以外で実行した場合には、　txt日付_入力用 にフォーカスが移動する　：Ｇｏｏｄ
    　** サブフォームのコマンドボタン：cmd予定追加 をマウス左クリックした時だけ、サブフォームのtxt日付_入力用 にフォーカスが移動しない：ＮＧ
    　** ＮＧ：手続き実行　prcサブフォームへフォーカスを移動( )
    　** 回避策として、時限タイマーの［タイマー1］イベントをインターバル 50/100秒で予約して、プログラムの流れを中断する

    ↑のコメント行のように、わざわざタイマーを使ったのは、

    　txt日付_入力用 → txt予定_入力用 → cmd予定追加 の操作の流れの中で、

    コマンドボタン：cmd予定追加を、

    ・［Enter］キーを押す　 ← main側で行追加後に、　　　 cmd予定追加 から txt日付_入力用 にフォーカスが移動する
    ・マウス左クリックする　← ＮＧ：main側で行追加後に、 cmd予定追加 から txt日付_入力用 にフォーカスが移動しない　※フォーカスは cmd予定追加 にある

    というＮＧに対処するためですよ。

    　　スケジュール表_subform_accept.wfx

    　　　フォーム
    　　　├ ファミリ
    　　　├ ワークスペース
    　　　│　└ cmd訂正
    　　　├ フォームヘッダ部
    　　　│　└ lbl説明
    　　　└ フォーム明細部
    　　　　　├ txt日付_入力用
    　　　　　├ txt予定_入力用
    　　　　　└ cmd予定追加

    とりあえず、タイマー経由で解決しましたので、それ以上の調査はしていません。

    今回のフォームは、メイン＆サブフォーム形式という、あくまでも試作ですので・・・(^^ゞ

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

▲[ 1473 ] / ▼[ 1485 ]
■1484 / 8階層) 　Re[8]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ジェダイの桐 -(2024/07/18(Thu) 16:12:49)
    2024/07/19(Fri) 10:10:26 編集(投稿者)
    2024/07/18(Thu) 16:25:52 編集(投稿者)
    2024/07/18(Thu) 16:24:17 編集(投稿者)
    2024/07/18(Thu) 16:21:43 編集(投稿者)
    2024/07/18(Thu) 16:20:45 編集(投稿者)

    ONnojiさん


    こんにちは！


    タイマーイベントの事が少し理解出来ました。


    任意のプロシージャの中で
    オブジェクト操作　@フォーム.タイマー1 = 1
    で　タイマーイベントを　オン　にする。

    　↓


    任意の時間プログラムを中断する

    　↓


    プロシージャ終了後　タイマーイベントが発生


    タイマーイベント内で　やりたい事があれば行い

    オブジェクト操作　@フォーム.タイマー1 = 0
    で　タイマーイベントを　オフ　にする。


    この認識であっているでしょうか？？


    何故タイマーイベントが理解かもしないかと言えば、

    AAAA　と　4桁の　文字列があり
    1桁で表現できるのは
    A　～　Z、0　～　9　の　36文字

    この条件でカウントアップしたい事がありました。


    こちらは実現出来たのですが、サンプル表に　3000行　あり　プログラムを実行していると　応答なし　と表示され　どうした物かと思案していました。


    ONnojiさんのHPで、プログレスバーの項目を見ていると　タイマーを使えば
    応答なし　を回避できるのでは？とヒントを貰い　サブフォームの件で作成頂いたサンプルを参考に　プログラムを書いてみたら　応答なし　が回避出来ました。


    パソコンに不可がかかる処理を分散させたい時等に　タイマーイベント　を使用するのだろうなと思いました。


    プログレスバー　をフォームヘッダに作りたいなと思いましたが断念しました。
    その代わり　近しい事で代用しました。


    桐って色んな事が出来るので、教えて頂いた知識を使って実現出来た時は本当に嬉しいです！


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

▲[ 1484 ] / ▼[ 1487 ] ▼[ 1486 ]
■1485 / 9階層) 　Re[9]: 多重化のメリット　時限式タイマーのメリット
□投稿者/ ONnoji -(2024/07/18(Thu) 17:29:11)
    2024/07/18(Thu) 17:46:12 編集(投稿者)

    ジェダイの桐さん

    > タイマーイベントの事が少し理解出来ました。
    > 任意のプロシージャの中で
    > オブジェクト操作　@フォーム.タイマー1 = 1
    > で　タイマーイベントを　オン　にする。
    > 　↓
    > 任意の時間プログラムを中断する
    > 　↓
    > プロシージャ終了後　タイマーイベントが発生
    >
    > タイマーイベント内で　やりたい事があれば行い
    >
    > オブジェクト操作　@フォーム.タイマー1 = 0
    > で　タイマーイベントを　オフ　にする。
    >
    > この認識であっているでしょうか？？

    タイマーイベント内で、処理をすればＯＫという単純なものではありませんよ。

    と書いて、よく見たら・・・

    以下のように


    手続き定義開始　フォーム::タイマー1()
    　変数宣言　自動, 文字列　{ &title, &msg }
    　変数宣言　自動, 整数　　{ &trace }

    　&title = "タイマー1()"
    　&trace = 0
    　トレース出力　&title + "を実行開始しました"

    　オブジェクト操作　@フォーム.タイマー1 = 0
    　条件　( &trace )　トレース出力　" オブジェクト操作　@フォーム.タイマー1 = 0　/* 時限タイマーの [タイマー1] イベントを停止 */"

    　トレース出力　&title + "を実行終了しました"

    手続き定義終了


    ↑上のように、タイマーイベントでは、何も実行していないではありませんか！

    実際には、タイマーイベント内で、何も実行していませんから・・・

    全然違うようですね。

    > 何故タイマーイベントが理解かもしないかと言えば、
    > AAAA　と　4桁の　文字列があり
    > 1桁で表現できるのは
    > A　～　Z、0　～　9　の　36文字
    > この条件でカウントアップしたい事がありました。
    > こちらは実現出来たのですが、サンプル表に　3000行　あり　プログラムを実行していると　応答なし　と表示され　どうした物かと思案していました。
    >
    > ONnojiさんのHPで、プログレスバーの項目を見ていると　タイマーを使えば
    > 応答なし　を回避できるのでは？とヒントを貰い　サブフォームの件で作成頂いたサンプルを参考に　プログラムを書いてみたら　応答なし　が回避出来ました。
    >
    > パソコンに不可がかかる処理を分散させたい時等に　タイマーイベント　を使用するのだろうなと思いました。
    >
    > プログレスバー　をフォームヘッダに作りたいなと思いましたが断念しました。
    > その代わり　近しい事で代用しました。
    >
    > 桐って色んな事が出来るので、教えて頂いた知識を使って実現出来た時は本当に嬉しいです！

    うーん、

    > サブフォームの件で作成頂いたサンプルを参考に　プログラムを書いてみたら　応答なし　が回避出来ました。

    ↑これって、タイマーとは全然関係ないと思いますよ。

    多重化して、多重化した方の表(.tbx)で作業しているでしょう。

    これが、ビジー（応答なし）を回避した原因だと思いますよ。

    試しに、

    タイマーを操作しているメソッドをコメントアウトしてみてください。

    　　オブジェクト操作　@フォーム.タイマー1 = 1
    　　オブジェクト操作　@フォーム.タイマー値1 = 25

    　　オブジェクト操作　@フォーム.タイマー1 = 0

    タイマーは動かなくなりますが、多重化によるパフォーマンスでビジー（応答なし）を回避しているので何も変わらない思いますよ。

    ということで、拝見したイベント処理では、無駄にタイマーをセットしリセットしているだけで、何の役にも立っていないと思いますよ。(^^ゞ

    ｐ．ｓ．

    多くの場合、多重化によるパフォーマンスでビジー（応答なし）を回避できると思いますよ。

    多重化してもパフォーマンスが悪い場合に、更にパフォーマンスを上げたい時に、時限タイマーによるプログレスバー方式を使います。

    しかし、プログレスバーを使う主な目的は、作業の中断を出来るようにすることですよ。
    　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・





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

▲[ 1485 ] / ▼[ 1488 ]
■1487 / 10階層) 　Re[10]: 多重化のメリット　時限式タイマーのメリット
□投稿者/ ONnoji -(2024/07/18(Thu) 18:26:21)
    2024/07/19(Fri) 00:40:54 編集(投稿者)

    ジェダイの桐さん

    蛇足を少々・・・(^^ゞ

    > タイマーイベント内で、処理をすればＯＫという単純なものではありませんよ。
    > 多くの場合、多重化によるパフォーマンスでビジー（応答なし）を回避できると思いますよ。
    >
    > 多重化してもパフォーマンスが悪い場合に、更にパフォーマンスを上げたい時に、時限タイマーによるプログレスバー方式を使います。
    >
    > しかし、プログレスバーを使う主な目的は、作業の中断を出来るようにすることですよ。
    > 　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    フォームの編集対象表を［イベント処理で多重化した表］は、双子の表ですが、一方がビジブルで、多重化した方はステルスな表ですね。

    このように、多重化した表と、［イベント処理で開いたステルスな表］を処理する場合には、

    フォームの編集対象を対象にした時と比べると、けた違いにパフォーマンスが良いです。

    つまり、フォームに見えている表は、レコードの移動によって再描画（リドロー）が発生しますので、

    その再描画（リドロー）がパフォーマンスを悪くさせているということです。

    　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇

    ステルスな表を扱っていても、ファイルのサイズが大きい場合や、レコード数が極端に多い場合、

    処理する内容が極端に複雑な場合、などにはパフォーマンスが悪くなります。

    例えば、

    Ａ．レコード数が多いけれど、１パスで処理を行う場合 ⇒ 時限タイマー１回につき処理するレコード数を決めます

    Ｂ．レコード数は多くないが、複数パスで処理を行う場合（結果的に処理レコード数が多くなったのと同じです）⇒時限タイマーから処理する内容ごとに手続きを呼び出します

    このような場合に、時限タイマーによるプログレスバーを検討するということですよ。

    ｐ．ｓ．

    Ａ．の場合には、以下のような感じ。※あくまでもアバウトなフィーリングです。細かいことは気にしないこと
    　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・・・・・

    手続き定義開始　prcプログレスバーを実行( )

    　&m処理単位レコード数 = 対象レコード数／回数

    　&mRecordCount 　 = 1
    　&mProgressBarRun = 1
    　ブジェクト操作　@フォーム｛ タイマー1 = 1, タイマー値1 = 10 ｝

    手続き定義終了

    手続き定義開始　フォーム::タイマー1()

    　if ( &mProgressBarRun )

    　　手続き実行　prcProgressbarCall( )
    　end

    手続き定義終了

    手続き定義開始　prcProgressbarCall( )

    　&count = 0　/* カウンタ */

    　繰り返し

    　　** プログレスバーで行う処理内容　例えば、一般手続きを実行　prcProcedureName()とか

    　　&count = &count + 1
    　　if ( &count > &m処理単位レコード数 .or #eof .or [Esc] キーを押した )

    　　　** プログレスバーの１回あたりの規定回数を実行した、または終端行に到達したので脱出する

    　　　繰り返し中止
    　　end
    　繰り返し終了

    　if ( [Esc] キーを押した または #eof )

    　　** [Esc] キーを押した、または終端行に到達したのでプログレスバーを終了する

    　　&mProgressBarRun = 0
    　　オブジェクト操作　@フォーム.タイマー1 = 0　/* タイマーをリセットする */
    　end

    手続き定義終了

    ※なお、[Esc] キーで中断するためには、［キーダウン］イベントをアクティブにして、[Esc] キーを検出する必要があります。


    Ｂ．の場合には、以下のような感じ。※あくまでもアバウトなフィーリングです。細かいことは気にしないこと
    　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・・・・・

    手続き定義開始　prcタイマーによる分割実行( )

    　&mPhase = 1
    　ブジェクト操作　@フォーム｛ タイマー1 = 1, タイマー値1 = 10 ｝

    手続き定義終了

    手続き定義開始　フォーム::タイマー1()

    　if ( &mPhase = 1 )

    　　手続き実行　prcPhasePrimaryRun( )
    　end

    　if ( &mPhase = 2 )

    　　手続き実行　prcPhaseSecondaryRun( )
    　end

    手続き定義終了


    手続き定義開始　prcPhasePrimaryRun( )
    　&mPhase = &mPhase + 1

    　** 処理内容

    手続き定義終了


    手続き定義開始　prcPhaseSecondarRun( )
    　&mPhase = &mPhase + 1

    　** 処理内容

    　&mPhase = 0
    　オブジェクト操作　@フォーム.タイマー1 = 0　/* タイマーをリセットする */

    手続き定義終了


    Ａ．

    　prcプログレスバーを実行 … インターバル … フォーム::タイマー1
    　　　　　　　　　　　　　　　　　　　　　　　└ prcProgressbarCall

    Ｂ．

    　prcタイマーによる分割実行 … インターバル … フォーム::タイマー1
    　　　　　　　　　　　　　　　　　　　　　　　　├ prcPhasePrimaryRun
    　　　　　　　　　　　　　　　　　　　　　　　　└ prcPhaseSecondaryRun

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

▲[ 1487 ] / 返信無し
■1488 / 11階層) 　Re[11]: 多重化のメリット　時限式タイマーのメリット
□投稿者/ ジェダイの桐 -(2024/07/19(Fri) 10:10:10)
    ONnojiさん


    おはようございます。


    タイマーに関わるプログラムのコメントアウト
    フォームのオブジェクトの属性からタイマーイベント　を　オフ

    上記を行いcmd資材品番カウントアップClick()　を実行しました。


    結果、ビジー（応答なし）は出てきませんでした。
    結論、あのプログラムにタイマーイベントは必要なく、ビジー（応答なし）回避は
    多重化によるものと言う事が理解出来ました！


    >>しかし、プログレスバーを使う主な目的は、作業の中断を出来るようにすることですよ。
    >>　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・


    進捗状況が見た目に分かる事は目的の一つで、主目的は作業の中断が出来ると言う事なのでしょうね(^^)
    確かにONnojiさんのHPにも、作業の中断が出来ると便利と書いていました。


    > Ａ．の場合には、以下のような感じ。※あくまでもアバウトなフィーリングです。細かいことは気にしないこと
    > 　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・・・・・


    プログレスバーの道しるべありがとうございます！
    いつの日か　プログレスバーが必要な時　こちらの道しるべを参考にプルグラムを考えます(^^ゞ


    解説ありがとうございましたm(__)m

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

▲[ 1485 ] / ▼[ 1489 ]
■1486 / 10階層) 　Re[10]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ジェダイの桐 -(2024/07/18(Thu) 18:24:47)
    ONnojiさん


    こんにちは！

    やっぱりタイマーイベントの事を聞いて良かったです！
    誤って理解する所でした。

    > 多重化して、多重化した方の表(.tbx)で作業しているでしょう。
    > これが、ビジー（応答なし）を回避した原因だと思いますよ。


    回避要因は多重化だったんですね！


    > タイマーを操作しているメソッドをコメントアウトしてみてください。


    明日早速試してみます。


    今回の件で　タイマーイベント　は登場しなくて
    良さそうと言う事が分かりました^_^


    > ということで、拝見したイベント処理では、無駄にタイマーをセットしリセットしているだけで、何の役にも立っていないと思いますよ。(^^ゞ


    半信半疑で　タイマーイベント　と書いてみて　見かけ上上手く行った様に
    みえたので失敗した事が分かった嬉しいです(^^)

    意外にも内容はないけど　タイマーセット　と　リセット　までは出来ていたのですね！
    セットする位置とタイマーイベント内の内容が重要なのでしょうね。

    >>サブフォームの件で作成頂いたサンプルを参考に　プログラムを書いてみたら　応答なし　が回避出来ました。


    こちらのサンプルでは、タイマーイベント内で　手続き実行をしていました。
    私も最初　タイマーイベント内で　手続き実行を行ったのですが、引数を入れていたのでエラーが起こりました。
    これは考えて見ればタイマーイベント内に関係のない引数でしたので当たり前の話です。


    タイマーイベント　に限らず　手続き内で　別の手続きを呼び出す時は　よく考えて使えば
    汎用性のある　プログラムになるし、他の影響を受けては行けない時に　手続きを呼び出すとエラーになる。


    プログラムの考え方って本当に良く出来ていると思います^_^


    勉強になりましたm(_ _)m
[ 親 1445 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 1486 ] / 返信無し
■1489 / 11階層) 　Re[11]: 「多重化のメリット　時限式タイマーのメリット
□投稿者/ ONnoji -(2024/07/19(Fri) 12:59:10)
    2024/07/19(Fri) 18:41:07 編集(投稿者)

    ジェダイの桐さん

    > タイマーに関わるプログラムのコメントアウト
    > フォームのオブジェクトの属性からタイマーイベント　を　オフ
    > 上記を行いcmd資材品番カウントアップClick()　を実行しました。
    > 結果、ビジー（応答なし）は出てきませんでした。
    > 結論、あのプログラムにタイマーイベントは必要なく、ビジー（応答なし）回避は
    > 多重化によるものと言う事が理解出来ました！

    でしょう。やっぱり。

    「イベント処理による編集対象表の多重化」は慣れれば簡単に出来るでしょ。

    パフォーマンスの向上は凄まじいです。

    そして、フォームに見えている編集対象表のレコードが移動しないのでサイレントです。

    > >>しかし、プログレスバーを使う主な目的は、作業の中断を出来るようにすることですよ。
    > >>　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    > 進捗状況が見た目に分かる事は目的の一つで、主目的は作業の中断が出来ると言う事なのでしょうね(^^)
    > 確かにONnojiさんのHPにも、作業の中断が出来ると便利と書いていました。

    確かに「進捗状況を見える化する」という目的もありますよ。

    整形ユーティリティでイベント処理ファイルを整形する時に、

    ［整形エンジン］と表示されたプログレスバーを表示する小さなフォームが現れますが、

    これが「作業の中断が出来るプログレスバー」です。

    ただし、これは難易度が非常に高いです。

    なぜかというと、主ウィンドウ（整形１～４）側には、整形エンジンが搭載されていなくて、

    「プログレスバーのフォーム」が進捗表示と実際の整形処理を行っているのです。

    この点は重要で、「外部プログレスバー（フォーム）」の場合には、

    単なる見かけ上のプログレスバーではなく、実体としての「モーダルフォームのプログレスバー」なのです。

    なので、難易度が高くなるのです。

    最初から「外部プログレスバー（フォーム）」を作るのは困難ですので、最初は内部プログレスバーにします。

    つまり、フォームヘッダ部にプログレスバー（ラベルオブジェクト）を配置します。

    この形式の例は、整形ユーティリティ（整形１～４）のフォームヘッダ部にある

    ［変数チェック］ボタンを実行して現れる「変数チェック」ウィンドウのプログレスバーです。

    >>Ａ．の場合には、以下のような感じ。※あくまでもアバウトなフィーリングです。細かいことは気にしないこと
    > プログレスバーの道しるべありがとうございます！
    > いつの日か　プログレスバーが必要な時　こちらの道しるべを参考にプルグラムを考えます(^^ゞ

    あたかも疑似コードのような、まるでポンチ絵のような、とてもアバウトなものを示しましたが、

    拙作ｗｅｂページの詳細な解説よりは取っ付き易いだろうと思います。

    頭の中で想像して、イメージが沸いたら拙作ｗｅｂページの詳細な解説を読んでみてください。

    　 ３５．１　内部プログレスバーと外部プログレスバー｜桐の釣魚大全のトップ > フォームアプリケーション教書　第２部
    　　http://silicon7565.html.xdomain.jp/guide/guide_Part2.htm#section35

    ヒントとか閃きが得られるかもしれませんよ。


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

▲[ 1445 ] / 返信無し
■1472 / 1階層) 　Re[1]: 「目からウロコの・・・パート２」を公開しました。
□投稿者/ ONnoji -(2024/06/24(Mon) 19:35:52)
    2024/06/24(Mon) 20:08:29 編集(投稿者)

    ジェダイの桐さん

    >>一通り動かして出力結果をクリップボードにコピーして、整形ユーティリティで整形したものを、
    >>｛ 画面で見る・ファイルに出力する・印刷する ｝方が落ち着いて見られますよ。
    > 実際に色々操作して、整形ユーティリティにコピペして見ました。
    > 感動しました。
    > 自分で作成したプログラムも、こちらにコピペしてみました。
    > 自分の思い通りに動いているのか・動いていないのかが可視化してくれるます。
    > なので実現したいプログラムの進捗状況が分かるのが素晴らしいと感じました。

    ［トレース出力］コマンドを利用して、プログラムの流れを可視化する方法を覚書としてまとめてみました。

    １．一般手続き（またはイベントハンドラ）に［トレース出力］コマンドを以下のように挿入します。

    　手続き定義開始　procedureName( )
    　　変数宣言　自動，文字列｛ &icon, &title = "procedureName( )", &msg ｝
    　　変数宣言　自動，整数　｛ &trace ｝

    　　&trace = 1
    　　条件　( &trace )　トレース出力　&title + "を実行開始しました"
    　　　：
    　　　：
    　　　：
    　　条件　( &trace )　トレース出力　&title + "を実行終了しました"
    　手続き定義終了

    　（重要）コピペしたためにウッカリ &title = "コピペしたprocedureName( )" を &title = "当該のprocedureName( )" に直し忘れるとお手上げになります。
    　　　　　必ず、&title = "procedureName( ) が正しい内容になっているか確かめてください。


    ２．［トレース出力］ウィンドウを設定して［トレース出力を開始］を選びます。

    　　詳しくは添付の画像を参照してください

    　　【参考】
    　　４０　［トレース出力］ウィンドウと［トレース出力］コマンド｜桐の釣魚大全のトップ > フォームアプリケーション教書　第２部
    　　http://silicon7565.html.xdomain.jp/guide/guide_Part2.htm#section40

    ３．この手続きが実行されると［トレース出力］ウィンドウに次のように出力されます。

    　　　　:procedureName( )を実行開始しました
    　　　　:procedureName( )を実行終了しました

    これを［トレース出力］ウィンドウの右メニューで［すべて選択］選び、もう一度右メニューで［コピー］を選ぶとクリップボードにコピー出来ます。

    ４．［整形ユーティリティ］のランチャー（utx_list3_launcher.wfx）の［トレース出力整形を開く］アイコンをクリックして、［トレース整形］ウィンドウを開きます。

    ５．［トレース整形］ウィンドウのヘッダにある［メモ帳を開く］ボタンを実行して、メモ帳を開きます。

    ６．次のメッセージボックスが表示されたら、［はい］を選択します。

    　　ファイルが空ではありません
    　　d:path\$$utx_list3_Trabe.txt
    　　内容をクリアしますか？
    　　［はい］［いいえ］［キャンセル］

    ７．メモ帳が開くので、クリップボードの内容を張り付け（ Ctrl + V ）て、メモ帳を保存終了します。

    　　※上書き保存（ Ctrl + S ）すると、自動的に［トレース整形］ウィンドウの［トレース整形］ボタンが実行されます。

    　　※メモ帳を開いてから、約１２０秒経過すると［トレース整形］ウィンドウが "タイムオーバーしました" とメッセージします。その場合にはメモ帳を閉じてください。


    ８．［整形エンジン（プログレスバー）］ウィンドウが現れてメモ帳に貼り付けた内容が読み易く整形されます。

    【メモ帳の内容】
    　　　　:procedureName( )を実行開始しました
    　　　　:procedureName( )を実行終了しました
    　　　　　　↓
    　　　　　　↓
    　以下のように整形されます
    　　　　　　↓
    　　　　　　↓
    【［トレース整形］ウィンドウの内容】

    ┌when :procedureName( )を実行開始しました
    └end


    ９．解説

    　　正しい手続き名である必要はなくて、任意の文字列でＯＫです。(^^ok

    　　　　トレース出力　○○〇を実行開始しました
    　　　　トレース出力　○○〇を実行終了しました
    　　　　　　↓
    　　　　　　↓
    　　　　:○○〇を実行開始しました
    　　　　:○○〇を実行終了しました
    　　　　　　↓
    　　　　　　↓
    　　　┌when :○○〇を実行開始しました
    　　　└end

    　　応用としては［手続き定義開始...手続き定義終了］の範囲以外にも、手続き内の任意の範囲を確認するためにも使えますよ。

    　■整形ユーティリティ　ダイアグラム

    　　出典　桐の釣魚大全のトップ > 整形ユーティリティ教書　基本編
    　　http://silicon7565.html.xdomain.jp/guide/guide_ReformUtility_Part1.htm

    　┌───────────────┐
    　│整形ユーティリティのランチャー│
    　│　　　　　　　　　　　　　　　│
    　└───┬───────────┘
    　　　　　↓
    　　┌──┴─────┐
    　　│トレース出力整形│
    　　│を開く　　　　　│
    　　└──┬─────┘
    　　　　　↓
    　　┌──┴───────────────────┐
    　　│トレース出力整形　　　　　　　　　　　　　　│
    　　│　　　　　　　　　　　　　　　　　　　　　　│
    　　└──┬────────────┬──────┘
    　　　　　│　　　　　　　　　　　　│
    　　┌──┴───┐　　　　　　┌─┴──┐
    　　│整形エンジン│　　　　　　│ﾃｷｽﾄ印刷│
    　　│　　　　　　│　　　　　　│　　　　│
    　　└──────┘　　　　　　└────┘
    　　　　　↑　　　　　　　　　　　　↓
    　　　　 入力　　　　　　　　　　　出力
    　　　　　↑　　　　　　　　　　　　↓
    　　┌──┴─────────┐┌────┐
    　　│メモ帳にペーストして　　││テキスト│
    　　│メモ帳を閉じます　　　　│└────┘┐
    　　│　　　　　　　　　　　　│　│プリント│
    　　└────────────┘　└────┘
    　　　　　↑
    　　┌──┴─────────┐
    　　│トレース出力ウィンドウの│
    　　│内容を右クリックして　　│
    　　│コピーします　　　　　　│
    　　└────────────┘

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

    >>なお、オブジェクトのリストは拙作整形ユーティリティの［フォーム定義リスト］で作図しています。
    > こちらも、整形ユーティリティを実際に使いました。
    > 頭を整理する時に、リスト図にしてくれるので非常に便利ですね！

    整形ユーティリティの［フォーム定義リスト］でオブジェクトのツリーを作図（テキスト）する方法を覚書としてまとめてみました。

    １．［整形ユーティリティ］のランチャー（utx_list3_launcher.wfx）の［フォームの定義リストを開く］アイコンをクリックして、［フォームの定義リスト］ウィンドウを開きます。

    ２．［フォームの定義リスト］ウィンドウのヘッダ部の［開く］または［ウィンドウ一覧］を実行して、任意のフォームを指定します。

    　　（注意）［ウィンドウ一覧］では現在ウィンドウとして開いているフォームだけしか一覧されません。

    ３．［フォームの定義リスト］ウィンドウのヘッダ部の［オブジェクトのリスト］ぼたんを実行します。

    ４．［オブジェクトのリスト］ウィンドウに表示されている次の箇所で
    　├ ファミリ
    　├ ワークスペース
    　├ フォームヘッダ部
    　├ フォーム明細部
    　└ フォームフッタ部

    　 Ctrl + マウス左クリックするとツリーを折り畳めます。
    　折り畳んだツリーは再び Ctrl + マウス左クリックすると表示されます。

    ５．［フォームの定義リスト］ウィンドウのヘッダ部の［テキスト］ボタンを実行して［テキストの保存］ダイアログでファイル名を入力して、［保存］ボタンを実行します。

    　　※同名のファイルが存在する場合には、上書きするか否か確認を求められます。


    ６．テキストの内容を見ますか
    　　［ＯＫ］［キャンセル］
    　　で［ＯＫ］ボタンを実行します。


    　■整形ユーティリティ　ダイアグラム

    　　出典　桐の釣魚大全のトップ > 整形ユーティリティ教書　基本編
    　　http://silicon7565.html.xdomain.jp/guide/guide_ReformUtility_Part1.htm

    　┌───────────────┐
    　│整形ユーティリティのランチャー│
    　│　　　　　　　　　　　　　　　│
    　└──┬────────────┘
    　　　　↓
    　　　　├───────┬────────┬────────┬────────┐
    　　　　↓　　　　　　　↓　　　　　　　　↓　　　　　　　　↓　　　　　　　　↓
    　┌──┴───┐┌──┴───┐┌───┴────┐┌──┴────┐┌──┴───────┐
    　│整形を開く　││クイック検索││dirでゲットだぜ ││表の定義リスト││フォームの定義リスト│
    　│　　　　　　││　　　　　　││　　　　　　　　││　　　　　　　││　　　　　　　　　　│
    　└──┬───┘└──┬───┘└───┬────┘└───────┘└──────────┘
    　　　　↓　　　　　　　↓　　　　　　　　↓

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

    > AKさんの推薦のことばに
    > 『これからイベント処理を勉強する方、既存のやり方に限界を感じている方にも十分推薦できるアプリ』
    > と言う意味を少し垣間見ました。
    > 何故少しなのかと言えば、整形ユーティリティを使いこなせていないからです。
    > もっと使用し、機能を使っていきたいと思います(^^♪

    整形ユーティリティは大工道具や治具と同じ類のものですよ。

    例えば、大工道具のノミやカンナは、見習いの使い手と熟練者では使い方が違ってくるものですよね。

    あくまでも、使い方次第であって、それは使う人のレベルに応じてくるものですよ。

    だから、整形ユーティリティがジェダイの桐さんのレベルをアップするのではなく、

    ジェダイの桐さんがレベルアップするから、整形ユーティリティの新しい使い方が見つかるということですよ。

417×550 => 189×250

1719227391.jpg/49KB
[ 親 1445 / □ Tree ] 返信 [メール受信/OFF] 削除キー/


Mode/　 Pass/

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

- Child Tree -
- Antispam Version -