DOWN LOAD BBS

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

[ 最新記事及び返信フォームをトピックトップへ ]

■653 / inTopicNo.1)  日付入力のイベントハンドラ
  
□投稿者/ ONnoji -(2025/09/04(Thu) 12:23:33)
    2025/09/05(Fri) 00:46:06 編集(投稿者)

    ジェダイの桐さんへ

    > 当方は現在、日時型の場合を研究しています。prcDateAccept というところです。(^^ゞ
    > 完成したらこの掲示板に投稿します。

    プロトタイプが一応完成しました。

    test_prototype_dateAccept_02.zipを解凍すると以下の4つのファイルがあります。

     test_prototype_dateAccept_02.kex
     test_prototype_dateAccept_02.tbx
     test_prototype_dateAccept_02.wfx
     test_prototype_dateAccept_02_test_prototype_dateAccept_02_info.txt

    是非そちらで試していただいて、ご意見・ご感想をよろしくお願いいたします。m(__)m

    なお、日時型のテキストボックス:txt日時 は、[環境設定]の[日時型の形式]のフォーマットで表示されます。

    文字列型のテキストボックス:txt文字列 は、デフォルトでは[環境設定]の[日時型の形式]のフォーマットで表示されますが、

    [名札 メイン]で &mDateAcceptDateTypeNum = 0, &mDateAcceptPaddingTypeNum を宣言するとフォーマットが変更できます。

     ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇

    名札 メイン

     ** prcDateAccept( ) で日付を文字列型項目(または変数)で扱う時のオプション変数
     ** "日付文字の表示形式" と "日付文字の数値の表示"のデフォルト値は "0:環境設定と同じ" ですが、
     ** 以下の↓変数宣言コマンドの先頭のコメント( ** )を削除すると有効になり任意のスタイルに変更できます
     ** 変数宣言 局所,整数 { &mDateAcceptDateTypeNum = 0, &mDateAcceptPaddingTypeNum = 0 }
     ** 日付を日時型項目(または変数)で扱う場合には、[環境設定]または[テキスト]オブジェクトの属性で指定してください
     ** -------------------------------------------------
     ** 表示形式を指定します。自動変数/整数/ &dateTypeNum
     **値 戻り値
     ** 0 環境設定と同じ形式 ← デフォルト:&dateTypeNum / prcDateAccept( )
     ** 1:2019年 7月25日 ( 13時23分45秒 )  2:2019年 7月25日 ( 午後 1時23分45秒 )  3:令和1年 7月25日 ( 13時23分45秒 )
     ** 4:令和1年 7月25日 ( 午後 1時23分45秒 ) 5:R 1/ 7/25 ( 13:23:45 ) 6:R 1/ 7/25 ( 1:23:45 PM ) 7:R 1- 7-25 ( 13:23:45 )
     ** 8:R 1- 7-25 ( 1:23:45 PM )  9:2019/ 7/25 ( 13:23:45 )  10:2019/ 7/25 ( 1:23:45 PM ) 11:2019- 7-25 ( 13:23:45 )
     ** 12:2019- 7-25 ( 1:23:45 PM ) 13:19/ 7/25 ( 13:23:45 )  14:19/ 7/25 ( 1:23:45 PM )  15:19- 7-25 ( 13:23:45 )
     ** 16:* 19- 7-25 ( 1:23:45 PM ) 17:Jul 25,2019 ( 13:23:45 ) 18:* 7/25/2019 ( 13:23:45 )  19:25 Jul 2019 ( 13:23:45 )
     ** 20:* 25/ 7/2019 ( 13:23:45 ) 21:2019. 7.25 ( 13:23:45 )
     ** [mm/dd/yyyy] または [dd/mm/yyyy] の表示形式を選択すると、日時関数で計算できない日時文字列になりますので、注意してください。
     ** -------------------------------------------------
     ** 数値の表示を指定します。自動変数/整数/ &paddingTypeNum
     **値 戻り値
     ** 0 環境設定と同じ ← デフォルト:&paddingTypeNum / prcDateAccept( )
     ** 1 空白詰め
     ** 2 ゼロ詰め
     ** 3 詰めなし
     ** -------------------------------------------------

     ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇

    <入力方法>

    年 月 日 をハイフン/スラッシュ/ドット/空白文字などで区切って入力してください。

    先頭の数字が 1 から 12 ⇒ 当年(2025年)と見做し月を指定したことになります
    先頭の数字が 13 から 99 ⇒ 2000年を加算します
    先頭の数字が 4桁    ⇒ 年として扱います( ただし 1945 から 2099 の範囲外はエラーになります )

    先頭に元号を付けることも出来ます

     ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇


     ■ test_prototype_dateAccept_02.wfx

     フォーム
     ├ ファミリ
     │ └ famModernUI
     ├ ワークスペース
     │ ├ INFtxtCommon
     │ ├ INFcmdCommon
     │ ├ cmdStartup
     │ └ cmdTest
     ├ フォーム操作バー
     ├ フォームヘッダ部
     │ ├ lblFlatButtonBorder_1
     │ ├ EZWcmdズームイン
     │ ├ EZWcmdズームアウト
     │ ├ EZWtxtMagnification
     │ ├ INFcmdWhoAreYou
     │ ├ HDLVARcmdWhoAreYou
     │ ├ ONEcmdUI変換
     │ └ chk項目値を範囲選択する
     │   └ lbl項目値を範囲選択する
     ├ フォーム明細部
     │ ├ txt文字列
     │ │ └ lbl文字列
     │ ├ txt日時
     │ │ └ lbl日時
     │ ├ txt長整数
     │ │ └ lbl長整数
     │ ├ txt数値
     │ │ └ lbl数値
     │ ├ txt通貨
     │ │ └ lbl通貨
     │ └ lblFlatButtonBorder_2
     └ フォームフッタ部
       └ lblFlatButtonBorder_3

    p.s.

    手続き:prcDateTestYear( ) 修正箇所 ※この修正は必須ではありません

    599行め(54行め)
    修正前
       ケース ( #対応番号( "S,s,昭和,昭", &prefix ) <> 0 )
    修正後
       ケース ( #対応番号( "S,s,S,s,昭和,昭", &prefix ) <> 0 )
     
    606行め(61行め)
    修正前
       ケース ( #対応番号( "H,h,平成,平", &prefix ) <> 0 )
    修正後
       ケース ( #対応番号( "H,h,H,h,平成,平", &prefix ) <> 0 )

    613行め(68行め)
    修正前
       ケース ( #対応番号( "R,r,令和,令", &prefix ) <> 0 )
    修正後
       ケース ( #対応番号( "R,r,R,r,令和,令", &prefix ) <> 0 )

    631行め(86行め)
    修正前
        &errorMsg = &errorMsg + "\n\n <ヒント>"
    修正後
        **&errorMsg = &errorMsg + "\n\n <ヒント>"

引用返信 [メール受信/OFF] 削除キー/
■654 / inTopicNo.2)  Re[1]: 日付入力のイベントハンドラ
□投稿者/ ジェダイの桐 -(2025/09/05(Fri) 15:32:36)
    2025/09/05(Fri) 16:03:05 編集(投稿者)

    ONnojiさん


    こんにちは!


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


    感想

     txt文字列 txt日時 への入力対応が柔軟で便利
      25y9m5d → 25/9/5

      無茶苦茶に入力しても対応してくれる
      25ttt9qqqq5oooo → 25/9/5( 実際はこんな入力をする人はいないと思いますが・・・ )

     元号対応も対応している
      R7-9-5 → 25/9/5( 西暦になおした日付になる )
      凄い所が &mDateAcceptDateTypeNum = 0 の値を 3 4 5 等に変更すれば表示方法が変わるところ
      自分の業務で使用したい表示にカスタム可能

     入力範囲外入力時のアナウンスが分かりやすい
      1944 9 5 → アナウンスが流れる
      2100 9 5 → アナウンスが流れる
      25/9/50  → アナウンスが流れる

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


    実現出来たらもっと良くなると思った事


     > 先頭の数字が 1 から 12 ⇒ 当年(2025年)と見做し月を指定したことになります
     > 先頭の数字が 13 から 99 ⇒ 2000年を加算します
     
     yy/mm/dd で入力する職場の場合

     00/9/5 → エラーではなく 00/9/5 となりたい
     12/9/5 → 25/9/5ではなく 12/9/5 となりたい

     と思いました。yy/mm/dd型 ではなく mm/dd型 の入力職場であれば現行で問題ないと思いました。

     私の職場は yy/mm/dd型 mm/dd型 どちらでもいいですが、yy/mm/dd型入力をする人が多いです。


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


    以上感想となります(^^ゞ


    p.s.


    test_prototype_dateAccept_02.kex の中身ですが高度過ぎて理解が難しかったです。
    トレース出力をみて多分こういう事をしてるんだろうなって感じた位です。

    多分

    手続き定義開始 prcDateTestPrefix で元号入力かを判断していて
    手続き定義開始 prcDateTestYear  で元号の場合は西暦計算している

    のだろうと思いました(^^ゞ( 推測なので当たっているかどうかは分かりませんが・・・ )


    p.p.s.

    今、test_prototype_dateAccept_02.kex を見ていて気付いたのですが、

    **(ご注意)非推奨ですが、INF_Framework.cmx に収録されている[イベントハンドラ]をイベント処理(.kex)側にコピーペーストして利用することは可能です。

    と言う文言を発見しました。

    Thin_INF_Framework ノート に書かれているイベントを使用する事はまずないのですが、

    その中でも使うかもしれないイベントが タイマー と レコード移動 イベントだったんです。
    タイマーイベントについては、以前回避策を教えて貰ったのですが、レコード移動を使いたくなったらどうするかな?
    と思っていたんですよ。

    質問なのですが、INF_Framework であっても、非推奨だけど、INF_Framework.cmx に収録されている[イベントハンドラ]をイベント処理(.kex)側にコピーペーストして利用することは可能なのでしょうか??





引用返信 [メール受信/OFF] 削除キー/
■655 / inTopicNo.3)  Re[2]: 日付入力のイベントハンドラ
□投稿者/ ONnoji -(2025/09/05(Fri) 16:03:13)
    ジェダイの桐さんへのお返事です。

    > 感想
    >  txt文字列 txt日時 への入力対応が柔軟で便利
    >   25y9m5d → 25/9/5
    >
    >   無茶苦茶に入力しても対応してくれる
    >   25ttt9qqqq5oooo → 25/9/5( 実際はこんな入力をする人はいないと思いますが・・・ )
    >
    >  元号対応も対応している
    >   R7-9-5 → 25/9/5( 西暦になおした日付になる )
    >   凄い所が &mDateAcceptDateTypeNum = 0 の値を 3 4 5 等に変更すれば表示方法が変わるところ
    >   自分の業務で使用したい表示にカスタム可能
    >
    >  入力範囲外入力時のアナウンスが分かりやすい
    >   1944 9 5 → アナウンスが流れる
    >   2100 9 5 → アナウンスが流れる
    >   25/9/50  → アナウンスが流れる
    > -----------------------------------------------------------------------------------

    いろいろと試していただいてありがとうございます。m(__)m

    文字列型のデータの場合には局所変数の値でフォーマットが変更できますから便利だと思います。

    ちなみに、日時型の場合には[環境設定]の[日時型の形式]のフォーマットで表示されます。

    > 実現出来たらもっと良くなると思った事
    >  > 先頭の数字が 1 から 12 ⇒ 当年(2025年)と見做し月を指定したことになります
    >  > 先頭の数字が 13 から 99 ⇒ 2000年を加算します
    >  
    >  yy/mm/dd で入力する職場の場合
    >  00/9/5 → エラーではなく 00/9/5 となりたい
    >  12/9/5 → 25/9/5ではなく 12/9/5 となりたい
    >
    >  と思いました。yy/mm/dd型 ではなく mm/dd型 の入力職場であれば現行で問題ないと思いました。
    >  私の職場は yy/mm/dd型 mm/dd型 どちらでもいいですが、yy/mm/dd型入力をする人が多いです。

    20世紀と21世紀をまたがない場合には、4桁( yyyy )よりも2桁( yy )が好まれるでしょうね。

    だって4桁( yyyy )では最初の2文字は "20" ですもんね。しかも、74年先まで、アハハハ(^^ゞ

    私( ONnoji )のように昔からPCを使っている人間からすると、いわゆる「2000年問題」を経験していますので、

    年を2桁で扱う事に抵抗があるんですよね。

    しかし、ちょっと考えてみることにしますね。

    > test_prototype_dateAccept_02.kex の中身ですが高度過ぎて理解が難しかったです。
    > トレース出力をみて多分こういう事をしてるんだろうなって感じた位です。
    > 多分
    > 手続き定義開始 prcDateTestPrefix で元号入力かを判断していて
    > 手続き定義開始 prcDateTestYear  で元号の場合は西暦計算している
    > のだろうと思いました(^^ゞ( 推測なので当たっているかどうかは分かりませんが・・・ )

    その通りです。

    泥縄式に作ったのですが、まあまあ格好になっていると思います。アハハハha


引用返信 [メール受信/OFF] 削除キー/
■656 / inTopicNo.4)  Re[3]: 日付入力のイベントハンドラ
□投稿者/ ONnoji -(2025/09/08(Mon) 08:51:00)
    2025/09/08(Mon) 09:10:19 編集(投稿者)

    ジェダイの桐さんへ

    test_prototype_dateAccept_03.zipを解凍すると以下の4つのファイルがあります。

     test_prototype_dateAccept_03.kex
     test_prototype_dateAccept_03.tbx
     test_prototype_dateAccept_03.wfx
     test_prototype_dateAccept_03_test_prototype_dateAccept_03_info.txt

    是非そちらで試していただいて、ご意見・ご感想をよろしくお願いいたします。m(__)m

     ◇ ◇ ◇ ◇ ◇ ◇ ◇

    以下↓をお読みください。m(__)m

    名札  メイン

     ** note: 日付文字と日時文字のイベントハンドラ IMTD( Input method ) 2025.09.07 by ONnoji
     ** IMTDprcDateAccept( ) で日付を文字列型項目(または変数)で扱う時のオプション変数
      ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
     ** 変数の値を書き換える必要はありません
       ・・・・・・・・・・・・・・・・・・
     ** [コマンドボタン:IMTDcmd日付文字列アイテム表示]を実行すると &IMTDmDateAcceptDateTypeNum  の値は書き換わります
       ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
     ** [コマンドボタン:IMTDcmd数字の表示アイテム表示]で実行すると &IMTDmDateAcceptPaddingTypeNum の値は書き換わります
       ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
     ** 変数の値は *_info.txt 保存されて次回オープン時に読み込まれます
       ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
     変数宣言 局所,整数 { &IMTDmDateAcceptDateTypeNum = 0, &IMTDmDateAcceptPaddingTypeNum = 0 }
     ** -------------------------------------------------
     ** 表示形式を指定します [コマンドボタン:IMTDcmd日付文字列アイテム表示]で確認できます
     **値 戻り値
     ** 0 環境設定と同じ形式
     ** 1: 2019年 7月25日  2: 2019年 7月25日
     ** 3: 令和1年 7月25日 4: 令和1年 7月25日
     ** 5: R 1/ 7/25    6: R 1/ 7/25
     ** 7: R 1- 7-25    8: R 1- 7-25
     ** 9: 2019/ 7/25    10: 2019/ 7/25
     ** 11: 2019- 7-25   12: 2019- 7-25
     ** 13: 19/ 7/25     14: 19/ 7/25
     ** 15: 19- 7-25    16: 19- 7-25
     ** 17: * Jul 25,2019  18: * 7/25/2019  19: * 25 Jul 2019  20: * 25/ 7/2019
     ** 21: 2019. 7.25
     ** [mm/dd/yyyy] または [dd/mm/yyyy] の表示形式を選択すると、日時関数で計算できない日時文字列になりますので、注意してください。
     ** -------------------------------------------------
     ** 数値の表示を指定します [コマンドボタン:IMTDcmd数字の表示アイテム表示]で確認できます
     **値 戻り値
     ** 0 環境設定と同じ
     ** 1 空白詰め
     ** 2 ゼロ詰め
     ** 3 詰めなし
     ** -------------------------------------------------
     ** 日付を日時型項目(または変数)で扱う場合には、[環境設定]または[テキスト]オブジェクトの属性で指定してください
     ** -------------------------------------------------

     ◇ ◇ ◇ ◇ ◇ ◇ ◇

    >  00/9/5 → エラーではなく 00/9/5 となりたい

    ⇒ 対応可能でしたので修正しました。(^^ok

    > × 12/9/5 → 25/9/5ではなく 12/9/5 となりたい

    > 〇 12/9/5 → 25/12/09ではなく 12/9/5 となりたい

    ⇒ 年を省略して mm/dd で指定す場合 12 は 12月と見做して、2012年とは見做しません。(^^ゞ

    > 20世紀と21世紀をまたがない場合には、4桁( yyyy )よりも2桁( yy )が好まれるでしょうね。
    > だって4桁( yyyy )では最初の2文字は "20" ですもんね。しかも、74年先まで、アハハハ(^^ゞ
    > 私( ONnoji )のように昔からPCを使っている人間からすると、いわゆる「2000年問題」を経験していますので、
    > 年を2桁で扱う事に抵抗があるんですよね。
    > しかし、ちょっと考えてみることにしますね。

    #日時文字列( &date, &dateTypeNum, &dateTimeScopeNum, &paddingTypeNum ) の第2パラメータに

     ** 13: 19/ 7/25     14: 19/ 7/25
     ** 15: 19- 7-25    16: 19- 7-25

    13〜15の値を指定すると、西暦を2桁で表示できます。

    これを応用すれば可能でした。

    ということで[コマンドボタン:IMTDcmd日付文字列アイテム表示]を実行して &IMTDmDateAcceptDateTypeNum の値を変更してください。

    これで年を2桁で扱う事に対応できると思いますが、いかがでしょうか?? (^^♪

    p.s.

    今回の「日付文字と日時文字のイベントハンドラ」は、IMTD( Input method )という名前空間にしました。

    これは、それ以外の変数名や手続き名と混在した時に衝突を避けるための処置です。アハハハha
        ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

引用返信 [メール受信/OFF] 削除キー/
■657 / inTopicNo.5)  Re[4]: 日付入力のイベントハンドラ
□投稿者/ ジェダイの桐 -(2025/09/08(Mon) 12:07:25)
    ONnojiさん


    こんにちは!


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

    >  ** note: 日付文字と日時文字のイベントハンドラ IMTD( Input method ) 2025.09.07 by ONnoji
    >  ** IMTDprcDateAccept( ) で日付を文字列型項目(または変数)で扱う時のオプション変数
    >   ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    >  ** 変数の値を書き換える必要はありません
    >    ・・・・・・・・・・・・・・・・・・
    >  ** [コマンドボタン:IMTDcmd日付文字列アイテム表示]を実行すると &IMTDmDateAcceptDateTypeNum  の値は書き換わります
    >    ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    >  ** [コマンドボタン:IMTDcmd数字の表示アイテム表示]で実行すると &IMTDmDateAcceptPaddingTypeNum の値は書き換わります
    >    ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・


    こっちの仕組みの方が、ユーザーは使うと思いました(^^ゞ
    プログラムの中でユーザーが直接数字を変更することは、出来る人と出来ない人が現れそうです。

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

    >> 00/9/5 → エラーではなく 00/9/5 となりたい
    >
    > ⇒ 対応可能でしたので修正しました。(^^ok


    有難うございますm(__)m


    >  ** 13: 19/ 7/25     14: 19/ 7/25
    >  ** 15: 19- 7-25    16: 19- 7-25
    >
    > 13〜15の値を指定すると、西暦を2桁で表示できます。
    > これを応用すれば可能でした。
    > ということで[コマンドボタン:IMTDcmd日付文字列アイテム表示]を実行して &IMTDmDateAcceptDateTypeNum の値を変更してください。
    > これで年を2桁で扱う事に対応できると思いますが、いかがでしょうか?? (^^♪


    はい!2桁表示になりました(^^ゞ

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

    >>〇 12/9/5 → 25/12/09ではなく 12/9/5 となりたい

    こちらは 25/12/09 のままです。

    良く考えました。
    実際 1 から 12 を年として入力する事は ほぼ有り得ない。

    今現在で有るとしたら、24 25 26 くらいでしょう。( 職種によっては分かりませんが・・・ )


    &subStringDim で 3トークン 以上あれば 第一トークン は 年 じゃないかな?
    と思ったんですけど、欧米風入力がありましたね・・・


    入力値が YMD DMY MDY なのかを推測するプロシージャを作成する事は可能なのかもしれませんが、
    1 から 12 を月と見做す方式の方が実用的だと思いました(^^ゞ
    ( 2025年なのだから、2001年 から 2012年 を入力する場面が想定しずらい。 )


    普段、何気なく入力している 日時型データ って、突き詰めて考えた時、難易度がかなり高いデータなんだなって思いました。
    第一トークンが 年 or 月 or 日 かを断定する方法を自分なりに考えてみましたが、どのアプローチでも穴が開いている気がしました。
    穴が開いていない仕組みを思いついたとしても、長いコードになると思いましたm(__)m







引用返信 [メール受信/OFF] 削除キー/
■658 / inTopicNo.6)  Re[5]: 日付入力のイベントハンドラ
□投稿者/ ONnoji -(2025/09/09(Tue) 10:29:11)
    2025/09/09(Tue) 12:26:54 編集(投稿者)

    ジェダイの桐さんへのお返事です

    >> ** note: 日付文字と日時文字のイベントハンドラ IMTD( Input method ) 2025.09.07 by ONnoji
    >> ** IMTDprcDateAccept( ) で日付を文字列型項目(または変数)で扱う時のオプション変数
    >> ** 変数の値を書き換える必要はありません
    >> ** [コマンドボタン:IMTDcmd日付文字列アイテム表示]を実行すると &IMTDmDateAcceptDateTypeNum  の値は書き換わります
    >> ** [コマンドボタン:IMTDcmd数字の表示アイテム表示]で実行すると &IMTDmDateAcceptPaddingTypeNum の値は書き換わります
    > こっちの仕組みの方が、ユーザーは使うと思いました(^^ゞ
    > プログラムの中でユーザーが直接数字を変更することは、出来る人と出来ない人が現れそうです。

    手続き:IMTDcmd数字の表示アイテム表示Click( )
    手続き:IMTDcmd数字の表示アイテム表示ClickRETURN( 整数 &itemMum )

    手続き:IMTDcmd日付文字列アイテム表示Click( )
    手続き:IMTDcmd日付文字列アイテム表示ClickRETURN( 整数 &itemMum )

    これらは HDLVAR を応用したものです。

             引数の意味:モーダル   タイトルバー文字 操作ガイド   配列変数名※[]なし 実行手続き名 終了状態※戻り値はINF_MNUがある:1 ない:0
     手続き実行 HDLAPIprcItem( &modalControl, &titlebarCaption, &operationGuide, &アイテム名配列DIM, &procedureName, &status )

    これは、INF_MNU.wfx/.kex を開きます。

    HDLVAR との違いは、カスタマイズできない点です。

    つまり、「アイテム選択」ダイアログのテンプレートになっているという事です。

    配列変数は要素数が50個までOKです。

    HDLAPIprcItem( )は、Thin INF_Framework を含めたすべての INF_Framework で利用可能ですよ。(^^ok

    このポップアップメニューは、拙作:整形ユーティリティや拙作:ランチャーでよく見かけるでしょう。アハハハha

    >> ** 13: 19/ 7/25     14: 19/ 7/25
    >> ** 15: 19- 7-25    16: 19- 7-25
    >>
    >>13〜15の値を指定すると、西暦を2桁で表示できます。
    >>これを応用すれば可能でした。
    >>ということで[コマンドボタン:IMTDcmd日付文字列アイテム表示]を実行して &IMTDmDateAcceptDateTypeNum の値を変更してください。
    >>これで年を2桁で扱う事に対応できると思いますが、いかがでしょうか?? (^^♪
    > はい!2桁表示になりました(^^ゞ

    最初は西暦から 2000 を差し引きしようかと考えていましたが、便利な関数があったのでそれを利用しました。(^^ok

    > >>〇 12/9/5 → 25/12/09ではなく 12/9/5 となりたい
    > こちらは 25/12/09 のままです。
    > 良く考えました。
    > 実際 1 から 12 を年として入力する事は ほぼ有り得ない。
    > 今現在で有るとしたら、24 25 26 くらいでしょう。( 職種によっては分かりませんが・・・ )
    > 1 から 12 を月と見做す方式の方が実用的だと思いました(^^ゞ
    > ( 2025年なのだから、2001年 から 2012年 を入力する場面が想定しずらい。 )

    年の二桁入力に関しては、エクセルをよく使う AKome さんからアドバイスをいただきました。感謝。

    > 普段、何気なく入力している 日時型データ って、突き詰めて考えた時、難易度がかなり高いデータなんだなって思いました。

    DOSの頃には桐以外のソフトでは、日付型というのがありました。

    Windows になってからは日付+時刻の日時型というのが一般的になったようですね。

    しかし、日時型の時刻の方はあまり使わないですね。アハハハha

    p.s.

    今回の IMTDprcDateAccept に関してフィードバックをいただいて誠にありがとうございます。m(__)m

    この機能は、任意で利用できると便利だと思います。

    INF_Framework の次期バージョンでフレームワークに取り込もうか?と考えています。

    ちなみに、拙作の新規開発は 桐9-2012 および 桐9s では行いません。

    残念ながら、古いソフトにいつまでも対応していられないから仕方がないですね。>ALL


引用返信 [メール受信/OFF] 削除キー/
■659 / inTopicNo.7)  Re[6]: 日付入力のイベントハンドラ
□投稿者/ ONnoji -(2025/09/11(Thu) 13:47:14)
    2025/09/12(Fri) 09:36:41 編集(投稿者)
    2025/09/11(Thu) 13:51:02 編集(投稿者)

    ジェダイの桐さんへ

    prototype_IMTD_01.zip を解凍すると以下の4つのファイルがあります。

     prototype_IMTD_01.kex
     prototype_IMTD_01.tbx
     prototype_IMTD_01.wfx
     prototype_IMTD_01_prototype_IMTD_01_info.txt

    今までの「まとめ」を行いました。

    是非そちらで試していただいて、ご意見・ご感想をよろしくお願いいたします。m(__)m

    p.s.

    データ入力時に、桐から表示されたエラーメッセージはとても分かり難いですよね。

     (i) 日時型入力に誤りがあります

    ↑このようなメッセージボックスが表示されても、意味が分からない人も居ますよね。

     (i) KD1053:数値データ形式に誤りがあります

    ↑これも同様で、意味がサッパリ分かりませんよね。

    これってどう考えても、桐側のユーザインタフェースが悪いんですよね。
               ・・・・・・・・・・・・・・・・・・・・

    だから、ちょっとだけ考察したというワケなんですよ。アハハハha

    p.p.s.

    アイテムメニューの表示に乱れがありました。

    以下のように修正をお願いします。

    手続き名:IMTDcmd日付文字列アイテム表示Click( )

    475行め(25行め)

    ×  ・・・,"19-10-15       西暦 2桁ハイフン区切り",\

    〇  ・・・,"19-10-15       西暦2桁 ハイフン区切り",\


prototype_IMTD_01.zip
/48KB
引用返信 [メール受信/OFF] 削除キー/
■660 / inTopicNo.8)  Re[7]: 日付入力のイベントハンドラ
□投稿者/ ジェダイの桐 -(2025/09/12(Fri) 15:28:17)
    ONnojiさん


    こんにちは!


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

    感想


    アイテム表示( 日付文字列の形式 )
    アイテム表示( 数字の表示 ) のアプローチが今までの中で一番分かりやすい

     → 選択後アナウンスが流れ何をセットしたのか一目で分かる為、ユーザーが納得しやすい設計となっている


    日付文字列 日時型 長整数型 数値型 通貨型 のエラー入力時のアナウンスが具体的でよい


    元号入力で元号の境目年 の扱いが自動処理になっていて親切

     R1/4/30 → 平成31年 4月30日
     R1/5/1  → 令和 1年 5月 1日
     H1/1/7  → 昭和64年 1月 7日
     S64/1/8 → 平成 1年 1月 8日


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

    ちょっと判断が難しい所


    異常値入力をしたとき、アナウンスが流れた後( 同時なのかな?? ) 編集選択位置設定 が全体選択になります。

    これをエラー対象へ、編集選択位置設定が範囲選択にならないかな?
    と思いました。

    例えば
     年でエラーをしたら 年が範囲選択
     月でエラーをしたら 月が範囲選択
     日でエラーをしたら 日が範囲選択

    ただし、これが実現出来るのか? と ユーザーにとって必要あるのか? が判断しきれなかったです。
    純粋にちょっと思った程度の発想ですm(__)m

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

    日付文字列 と 日時型 の入力について


    アイテム表示ボタンで選択しているので、ほとんどのユーザーはこんな事をしないと思いますが、

    250912 と 入力した場合

     日付文字列 → KU1117:値が範囲を超えています 詳細 : &num ・・・
     
     日時型   → KU1117:値が範囲を超えています 詳細 : &num ・・・
     日時型   → フォーム:(5188) 日時型入力に誤りがあります(-6)

    と桐側のアナウンスが流れます。共に 行番号は 602 で起こる様です。

    ここがもう少し、ユーザーに分かりやすいアナウンスが流れればいいなと思いましたm(__)m

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


    以上、私の感想となります(^^ゞ


引用返信 [メール受信/OFF] 削除キー/
■661 / inTopicNo.9)  Re[8]: 日付入力のイベントハンドラ
□投稿者/ ONnoji -(2025/09/13(Sat) 08:28:39)
    2025/09/13(Sat) 08:34:30 編集(投稿者)

    > アイテム表示ボタンで選択しているので、ほとんどのユーザーはこんな事をしないと思いますが、
    >
    > 250912 と 入力した場合
    >  日付文字列 → KU1117:値が範囲を超えています 詳細 : &num ・・・
    >  
    >  日時型   → KU1117:値が範囲を超えています 詳細 : &num ・・・
    >  日時型   → フォーム:(5188) 日時型入力に誤りがあります(-6)
    >
    > と桐側のアナウンスが流れます。共に 行番号は 602 で起こる様です。
    > ここがもう少し、ユーザーに分かりやすいアナウンスが流れればいいなと思いましたm(__)m

    数値系の変数のデータ型に誤りがありました。

    誤りと言うより、扱える数値の範囲が狭すぎました。(^^ゞ

    以下のように、4つの手続きの該当箇所を修正してください。m(__)m

    ■手続き名:IMTDprcDateAccept( )

    × 変数宣言 自動,整数 { &num }
    〇 変数宣言 自動,数値 { &num }

    × 変数宣言 自動,整数 { &year, &month, &day }
    〇 変数宣言 自動,数値 { &year, &month, &day }

    ■手続き名:IMTDprcDateTestYear( )

    × 手続き定義開始 IMTDprcDateTestYear( ・・・, 参照 整数 &year, ・・・ )

    〇 手続き定義開始 IMTDprcDateTestYear( ・・・, 参照 数値 &year, ・・・ )
                                ・・

    ■手続き名:IMTDprcDateTestMonth( )

    × 手続き定義開始 IMTDprcDateTestMonth( ・・・, 参照 整数 &month, ・・・ )

    〇 手続き定義開始 IMTDprcDateTestMonth( ・・・, 参照 数値 &month, ・・・ )
                                ・・

    ■手続き名:IMTDprcDateTestDay( )

    × 手続き定義開始 IMTDprcDateTestDay( ・・・, 整数 &num, 参照 整数 &day, ・・・ )
    〇 手続き定義開始 IMTDprcDateTestDay( ・・・, 数値 &num, 参照 数値 &day, ・・・ )
                            ・・       ・・
     ◇ ◇ ◇ ◇ ◇ ◇ ◇

    > ちょっと判断が難しい所
    > 異常値入力をしたとき、アナウンスが流れた後( 同時なのかな?? ) 編集選択位置設定 が全体選択になります。
    > これをエラー対象へ、編集選択位置設定が範囲選択にならないかな?
    > と思いました。
    > 例えば
    >  年でエラーをしたら 年が範囲選択
    >  月でエラーをしたら 月が範囲選択
    >  日でエラーをしたら 日が範囲選択
    > ただし、これが実現出来るのか? と ユーザーにとって必要あるのか? が判断しきれなかったです。
    > 純粋にちょっと思った程度の発想ですm(__)m

    誰でもそう思いますよね。私自身もそう思いました。

    しかし、区切り文字を、自由・フリーに入力できるので

    >  txt文字列 txt日時 への入力対応が柔軟で便利
    >  25y9m5d → 25/9/5
    >  無茶苦茶に入力しても対応してくれる
    >  25ttt9qqqq5oooo → 25/9/5( 実際はこんな入力をする人はいないと思いますが・・・ )

    年月日のどこに誤りがあったかはメッセージボックスで通知していますが、

    入力された文字列( 入力後イベントハンドラの引数:&編集文字列 )の年月日の位置を特定するのが難しいんですよ。

    ということで無駄な努力はしていないのです。ガハハハ。

    ちなみに、全体選択にする理由は、[BS]キーや[Delete]キーで一発削除できると便利だからです。

    間違った入力の時には、部分修正するよりも、最初からやり直すのが一番確実だからです。ガハハハha
    ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

     ◇ ◇ ◇ ◇ ◇ ◇ ◇

    > 250912 と 入力した場合

    「2桁の年+2桁の月+2桁の日」で入力した場合はどうしようか????

    この場合には、2文字ずつ年月日に分解して、それぞれの値をチェックすればOKです。

    このようなデータを入力する人も多いと思います。

    もちろん、この場合の利点もあるわけですが・・・(^^ゞ

    しかし、困ったことに区切りがない文字列は "日付文字列" にならないわけですよ。
              ・・・・・・・・・・・・・・・・・・・・・・

    なので、この場合には 250912年 として処理するワケです。

    ということで、日時型は "日時文字列" 、文字列型は "日付文字列" と扱うようにする仕様でありました。(^^ok
                ・・・・・        ・・・・・

     ◇ ◇ ◇ ◇ ◇ ◇ ◇

    > 感想
    > アイテム表示( 日付文字列の形式 )
    > アイテム表示( 数字の表示 ) のアプローチが今までの中で一番分かりやすい
    >  → 選択後アナウンスが流れ何をセットしたのか一目で分かる為、ユーザーが納得しやすい設計となっている
    > 日付文字列 日時型 長整数型 数値型 通貨型 のエラー入力時のアナウンスが具体的でよい

    今回も具体的なフィードバックをいただきありがとうございます。m(__)m

    当方は漫然としていて、データ型をよく吟味しなかったので、ご指摘をいただいて本当に助かりました。感謝。

    とりあえず、今回で IMTD の物語は最終回のつもり(予定)です。

    しかし、さらにお気づきの点があれば、お手数ですがお知らせいただければ幸いです。

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

    それでは。 (@^^)/~~~

引用返信 [メール受信/OFF] 削除キー/
■662 / inTopicNo.10)  Re[9]: 日付入力のイベントハンドラ
□投稿者/ ジェダイの桐 -(2025/09/13(Sat) 10:56:01)
    ONnojiさん


    こんにちは!


    数値型 通貨型 の 入力フィールド に

    99999999999999999999999999999999999999999999999( これこそユーザーは入力する事が無いと思いますが・・・ )

    と入力すると

    KU1030:演算中に桁あふれが発生しました 行番号 980
    と共に桐側のアナウンスが流れました。


    一応、報告しますm(__)m


引用返信 [メール受信/OFF] 削除キー/
■663 / inTopicNo.11)  Re[10]: 日付入力のイベントハンドラ
□投稿者/ ONnoji -(2025/09/13(Sat) 11:40:37)
    2025/09/13(Sat) 11:54:18 編集(投稿者)

    ジェダイの桐さんへのお返事です

    > 数値型 通貨型 の 入力フィールド に
    > 99999999999999999999999999999999999999999999999( これこそユーザーは入力する事が無いと思いますが・・・ )
    > と入力すると
    >
    > KU1030:演算中に桁あふれが発生しました 行番号 980
    > と共に桐側のアナウンスが流れました。
    > 一応、報告しますm(__)m

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

    手続き名:IMTDprcNumAccept( ) の

      &string = #str( #num( &string ) )

    ↑この部分で #数値( 別名:#num )関数の計算中に桁あふれが生じたということですね。
           ・・・・・・・・・・・・・・・・・・・・・・・・・・

        :prototype_IMTD_02.wfx hdl= 1>IMTDprcNumAccept( )を実行開始しました
        :&objectName : txt数値 &dataType : 数値 &source : [数値型]
        :( #対応番号( &dataTypeList, &dataType ) <> 0 ) : 1
        :&string : 99999999999999999999999999999999999999999999999
        :&dataType : 数値 &source : [数値型]
    エラー :KD1570:計算中に桁あふれが生じました 関数 : #数値(D:\kiri10s\dl_conv_INF_Framework_2022_Secondary\prototype_IMTD_02.tbx )
    エラー :KU1030:演算中に桁あふれが発生しました(D:\kiri10s\dl_conv_INF_Framework_2022_Secondary\prototype_IMTD_02.kex 980行目)

    まあ、これは仕方が無い事ですね。

    &string : 99999999999999999999999999999999999999999999999 は46桁の文字列 で、

    この場合、9.999999999999999E46 は 有効桁数:16 桁 の指数表示になる

    のですが・・・

      [桐 - ヘルプ]
      データ型
      ▽数値
      数値とプラスマイナス符号、小数点、指数記号(Eまたはe)が入力できます。
      扱える値の範囲は±10の124乗です(有効桁数:16 桁)。
      JAN、ITF、物流コードのバーコードデータは、このデータ型で扱うことができます。


    ということで、やるとすれば、16桁以上の整数は事前にエラーにする位ですかねぇ〜?

    でも、そこまで気を遣う必要なないと思いますよ。(^^ok

    p.s.

    コンピュータでの数値演算には、二進演算と二進化十進演算があります。

    桐の整数・長整数・数値・通貨は二進化十進演算で、演算誤差がありません。

    しかし、桐の実数型は二進演算なので、小数を含む演算をすると誤差が生じますので使わないようにしてください。
        ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    以下の過去ログもご一読ください。

    コチラ
     ↓
    エクセルで計算結果エラー|桐質問のほかの掲示板 過去ログより
    http://tayu.o0o0.jp/bbs/kiri/cbbs.cgi?mode=al2&namber=1312&no=1

    p.p.s.

    <参考>

    [桐 - ヘルプ]
    データ型

    桐では、データの種類に応じて9種類のデータ型を用意しています。

    ▽文字列
    氏名や電話番号、商品名など、文字列を扱うデータ型です。画像ファイル名やバーコードも、このデータ型を使用します。
    最大8000文字を扱うことができます(※注意:ただし、索引の整列項目は2000文字までです)。

    ▽数値
    数値とプラスマイナス符号、小数点、指数記号(Eまたはe)が入力できます。
    扱える値の範囲は±10の124乗です(有効桁数:16 桁)。
    JAN、ITF、物流コードのバーコードデータは、このデータ型で扱うことができます。

    ▽通貨
    基本的に数値型と同じです。表の中では3桁ごとの位取りコンマで区切って表示されます。

    ▽整数
    -32768〜32767の整数を扱うときに使用します。小数点以下の数値は扱えません。

    ▽長整数
    -2147483648〜2147483647の整数を扱うときに使用します。小数点以下の数値は扱えません。

    ▽実数
    科学計算や外部データベースとの互換のために設けられたデータ型です。
    数値とプラスマイナス符号、小数点、指数記号(Eまたはe)が入力できます。
    扱える値の範囲は±1.79769313486231e+308です(有効桁数:15〜16桁)。
    実数型の演算は、常に誤差が生じる可能性があるため、お金などを扱うデータ型としては適しません。
    ・・・・・・・・・・・・・・・・・・・・・・
    通常、扱う数値を格納する項目は、数値型または通貨型を使用してください。
    ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・


引用返信 [メール受信/OFF] 削除キー/



トピック内ページ移動 / << 0 >>

このトピックに書きこむ

Mode/  Pass/

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

- Child Tree -
- Antispam Version -