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

■15162 / 親記事) 　制約について
  ▼■
□投稿者/ キリマンジャロ -(2025/10/30(Thu) 13:04:09)
    IN11、桐10S使用です
    いつもお世話になっております

    今回ですが、データ型　文字列、項目名　機械No
    という表のデータがあります。

    ここにP01 や　R01　や　T05　など頭が英語で
    そのあと2文字が数字で入ります。

    入力する際に、P1やP5などにならない様に3桁
    しか入らないように、制約を付けたいを思いましたが
    やり方が分からなかったので、
    忙しいところ恐縮ですが教えて頂きたいです。
    宜しくお願い致します。
引用返信 [メール受信/OFF] 削除キー/
■15163 / ResNo.1) 　Re[1]: 制約について
□投稿者/ ジェダイの桐 -(2025/10/30(Thu) 13:40:23)
    キリマンジャロさん


    こんにちは。


    表の再定義画面にする。

    項目名　機械No　の　項目属性　→　制約タブ　→　項目制約式　へ

    #文字数( [機械No] ) = 3

    と入力すれば、3文字入力でないとエラーがでます。

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

    ただこの方法を実装しても、根本解決にならないのじゃないかな？
    と思いました。

    先頭文字　アルファベット　+　残り　文字列数字

    の構成が正しいのに、　例えば　この方法だと　111　でも　通りますからね。　

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

    もっといい方法があるような気がします(^^ゞ


引用返信 [メール受信/OFF] 削除キー/
■15164 / ResNo.2) 　Re[1]: 制約について
□投稿者/ ONnoji -(2025/10/30(Thu) 14:39:12)
    2025/10/30(Thu) 15:03:10 編集(投稿者)

    > 入力する際に、P1やP5などにならない様に3桁
    > しか入らないように、制約を付けたいを思いましたが
    > やり方が分からなかったので、

    裸の表（.tbx)に直接入力しているのですか？？？

    ｐ．ｓ．

    貴殿はお忙しいのかと存じますが、基本的な事柄の場合には、質問する前にヘルプをお読みになることをおススメします。
    　　　　　　　　　　　　　　　　・・・・・・・・・　　　・・・・・・・・・・・・・・・・・・・・・・・・・・

    質問に回答する人の多くが［桐 - ヘルプ］を確認しているのですからね・・・(ーー;)--------------> ※遠い目線

    ［桐 - ヘルプ］ > 表定義 > 項目属性 > 制約 > [項目制約式]

    【転載】https://www.kthree.co.jp/kihelp/index.html?page=tbl/tfProp3&type=html

    [項目制約式]
    項目に登録できるデータを制限する場合は、条件式を入力します。[式入力]エディタを使用して条件式を入力するには をクリックします。
    この制約は、項目の編集が終了した時点で評価されます。
    この項目の値が未定義のときは評価されません。未定義を禁止する場合は[未定義禁止]をONにしてください。
    条件式の中に、設定項目以外の項目名を含めてはいけません。他の項目を使用して入力できる値を制限するには、行制約式を使用してください。

    　
    （例） []>=1 .and []<=31 …　1以上、31以下の値を許可する。
    （例） #文字数([])<=10 …　文字数が10文字以内。

    また、［項目属性］ダイアログのタイトルバーの［？］ボタンを押してもヘルプが表示されますよ。
    　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

引用返信 [メール受信/OFF] 削除キー/
■15165 / ResNo.3) 　Re[2]: 制約について
□投稿者/ ONnoji -(2025/10/30(Thu) 16:18:48)
    2025/10/30(Thu) 16:25:33 編集(投稿者)

    掲示板の過去ログも参考にしてください。

    こちら
    　↓
    表定義で、桁をそろえる方法 → 利用者に色で警告することは可能　｜　過去ログ50
    http://tayu.o0o0.jp/bbs/kiri/cbbs.cgi?mode=al2&namber=7811&no=0&KLOG=50

    入力中にメッセージボックスでエラーを表示するよりも、文字の色を変えるだけで十分警告になりますよ。
    　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    ＜参考＞
    ■7812 / inTopicNo.2) 　利用者に色で警告することは可能
    □投稿者/ ONnoji -(2014/01/30(Thu) 11:05:45)

    http://tayu.o0o0.jp/bbs/kiri/file/1391047545.jpg

    > 表定義の項目制約式で、入力を制限することが出来ますね。
    > しかし、…
    > 値が項目制約条件に違反しています［ＯＫ］
    > というメッセージボックスから、
    > 果たして利用者が文字数を３文字に修正すればよいと気が付くでしょうか？？
    > 前へ進めずに立ち往生して、利用者がパニックになる恐れが非常に高いので、
    > 項目制約式はオススメしませんよ。

    > 表定義で、エラーメッセージを設定すれば、任意のメッセージが表示できますね。
    > しかし、メッセージボックスを表示するのは、
    > 利用者の入力作業のリズムを狂わせるので、やはりオススメしませんよ。
    > 利用者の入力作業のリズムは大切です。
    > 色を変えるだけで、利用者は十分気が付くはずですよ。

引用返信 [メール受信/OFF] 削除キー/
■15166 / ResNo.4) 　Re[3]: 制約について
□投稿者/ ONnoji -(2025/10/30(Thu) 16:39:16)
    2025/10/30(Thu) 16:43:50 編集(投稿者)

    > 入力中にメッセージボックスでエラーを表示するよりも、文字の色を変えるだけで十分警告になりますよ。
    > 　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    以下はかつて存在した［桐のイベント道場］からの一部転載です

    【イベント初心者講座　その５　または The Compleat Angler For Kiri　桐Ｖ８の釣魚大全】より
    　藤野さんのイベント初心者講座　 compleat_angler_overview.zip

    ONnoji 2002年02月16日 22時33分

    　：
    　：

    空欄に文字を記入していく（空欄記入型）のデザインの場合、
    入力作業の途中で再入力を強制するのはいいことではありません。

    住所追加フォームの場合では、氏名の入力は必須ですが、
    うっかり［Enter］や［Tab］を押す事だってありますよね。

    それだけのことで、"氏名が入力されてません"とメッセージを出すというのは、
    作り手の藤野さんにとって良くても、
    使う人からすれば他の入力域でも同じようなことが起きるだろうと予想します。
    これはまるで目隠しをして地雷原を歩くようなもので、安心して操作ができません。(~_~;)

    ところで、少し寄り道のお話をします…これは重要なことです。

    誰でも、初心者 → 上級者 → プロフェッショナル → エキスパート という段階のどこかに位置します。
    これはコンピュータ操作に限らず、すべての事柄に当てはまります。

    あるフォームを操作する場合、利用者はいつまでも初心者のレベルで留まっているわけではありません。
    はじめて操作するフォームの場合、最初は初心者のレベルです。
    しかし、段段と操作に慣れてすぐに（ある程度自分で判断できる）上級者になります。

    今回のように、「メッセージボックスを表示して、再入力を強制する」というのは
    初心者には歓迎されるでしょうけれど、
    操作に慣れた上級者にとっては、わずらわしいだけです。
    感謝するどころか、このフォームを作った人を罵りたくなります。
    「どうしてこの馬鹿ソフトはこんなにもガチガチなんだ！！！」とですね。

    この段階で、作り手と利用者は反目しあうことになります。
    こういう経験は藤野さん自身もたくさんしていると思います。
    ですから、作り手は「利用者はいつまでも初心者のレベルに留まっていない」ということを自覚するべきです。

    さて、話しを元に戻しましょう。

    利用者に地雷を踏ませないようにするには、"ここに地雷が埋まっていますよ！"と教えてあげる方法があります。
    例えば、インターネットで名前を入力するフォームの場合には、"全角で入力"とかありますよね。
    私達はそれを見て、ここは全角で入力するのだなと直感的に理解しているのです。
    ですから、氏名の入力域の近くに（上または右）に"必須"とコメントするだけで、利用者は注意深くなります。
    たったこれだけのことで、地雷を踏んで利用者が作者を罵ることを防げます。
    "必須"というたった二文字のコメントですが、これは道路標識のような役目をするのです。
    運転中に「制限速度４０Km」という道路標識を認めれば、我々は無意識に注意して運転します。
    しかし、何も道路標識がない道路を通行中に、突然ねずみ取りで捕まったなら、きっと頭に来るでしょう？

    したがって、入力域の近くにコメントを用意するというのはいい方法です。
    しかし、コメントは必要最小限にしなければ意味がありません。
    運転中に同時にたくさんの道路標識を一度に見せられたら、混乱するだけですよね。(^^ゞ

    その他の方法としては、氏名欄に文字を入力しないで次の項目へ移った時に、
    フォームの決まった場所（一般的にはフォームの左下）に、"氏名が入力されていません"と表示する方法もあります。
    利用者がこのメッセージを認めることで、即座に入力ミスに気が付くというわけですね。
    利用者がこの暗黙のルールを了解していれば、ただちに入力ミスを修正する操作にとりかかるはずですね。(^^ゞ

    どうでしょうか、「メッセージボックスを表示して、再入力を強制する」方法に比べれば、
    このほうがユーザに優しいとは思いませんか？

    　：
    　：

引用返信 [メール受信/OFF] 削除キー/
■15167 / ResNo.5) 　Re[4]: 制約について
□投稿者/ ONnoji -(2025/10/30(Thu) 23:21:33)
    2025/10/31(Fri) 10:35:31 編集(投稿者)

    入力中にメッセージボックスでエラーを表示するよりも、文字の色を変えるだけで十分警告になりますよ。
    　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    表の編集状態 → メニューバー → 属性メニュー → 項目の編集条件 → 編集条件

    条件式

    ⇒　#is英字( #sstr([],1,1 ), 1 ) = 0 .or #is数字( #sstr([], 2, 2 ), 1 ) = 0 .or #文字数( [] ) <> 3

    ⇒　背景色：赤


    ｐ．ｓ．


    【テキストボックスの編集属性式】の場合には

    #cond( ( #is英字( #sstr([機械No],1,1 ), 1 ) = 0 .or #is数字( #sstr([機械No], 2, 2 ), 1 ) = 0 .or #文字数( [機械No] ) <> 3 ),"背景色'赤'" )


引用返信 [メール受信/OFF] 削除キー/
■15168 / ResNo.6) 　Re[2]: 制約について
□投稿者/ ONnoji -(2025/10/31(Fri) 09:03:10)
    2025/10/31(Fri) 09:18:15 編集(投稿者)

    ■No15163に返信(ジェダイの桐さんの記事)
    > ただこの方法を実装しても、根本解決にならないのじゃないかな？
    > と思いました。
    >
    > 先頭文字　アルファベット　+　残り　文字列数字
    >
    > の構成が正しいのに、　例えば　この方法だと　111　でも　通りますからね。　
    >
    > もっといい方法があるような気がします(^^ゞ

    ジェダイの桐さん横レス失礼します。

    フォームを使うのならば、テキストボックスの［入力後］イベントハンドラで判定すると思いますが、

    それはそれで面倒ですよね。

    なので、テキストボックスの［編集属性式］属性に次の式を使うと

    　#cond( (( #is英字( #sstr([機械No],1,1), 1 ) <> 1 ) + ( #is数字( #sstr([機械No], 2, 2), 1 ) <> 1 ) + ( #文字数( [機械No] ) <> 3 ) > 0 ),"背景色'赤'" )

    条件を満たさない場合に背景色を赤色にします。

    もちろん、背景色の替わりに文字色でもＯＫです。

    なお、上で紹介した式はオートINF_Framework が表(.tbx)の［項目の編集条件］の設定をテキストボックスの［編集属性式］属性に自動で置き換えたものです。
    　　　　　　　　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    ということで、オートINF_Framework を使用するのであれば、表(.tbx)の［項目の編集条件］だけをセットするだけでＯＫです。

    後は、オートINF_Framework がテキストボックスの［編集属性式］属性を自動的に設定します。

    ｐ．ｓ．

    なお、この条件式は

    #is英字( #sstr([],1,1),　1 )　<> 1 … 項目値の１文字めから１文字が英字ではない
    #is数字( #sstr([], 2 ,2), 1 ) <> 1 … 項目値の２文字めから２文字が数字ではない
    #文字数( [] ) <> 3　　　　　　　　 … 項目値の文字数が３ではない

    この３つを and で結べばＯＫなのですが、２つの条件の and は正常に動くのですが、なぜか３つの条件だと正しく動きません。※桐10ｓの場合

    そこで、仕方なく　( 条件式 ) + ( 条件式 ) + ( 条件式 ) > 0 と算術的に条件式を作りました。(^^ゞ

    ｐ．ｐ．ｓ．

    > フォームを使うのならば、テキストボックスの［入力後］イベントハンドラで判定すると思いますが、
    > それはそれで面倒ですよね。

    ＜参考＞

    桐の釣魚大全のトップ > フォームアプリケーション教書　第１部
    https://silicon7565.cloudfree.jp/guide/guide_Part1.htm#section16-3

    １６．３　テキストボックスのイベント

    　―［入力後］イベント
    　　エディタから脱出する直前に発生するイベントです。
    　　このイベントではまだエディタから脱出していません。
    　　・引数：&編集文字列
    　　　編集した文字列を最適化する場合には、引数：&編集文字列 の値を変更します
    　　・引数：&モード
    　　　確定（［Enter］キーや［F4］キー）か破棄（ [Esc]キーによるキャンセル）を判定する
    　　・引数：&入力継続
    　　　イチ(1)を代入するとエディタから脱出しないで、再び編集エディタに戻る
    　　　　↑
    　　　※著者( ONnoji )注：安易にこれを使用すると、ユーザが混乱する恐れがあります。
    　　　　　　　　　　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・
    　　　使用に当たっては、メッセージボックスを表示してユーザの意思を確認することが望ましいです。
    　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    　　　なお、入力値に誤りがある場合には、再び編集エディタに戻らず、テキストボックスの文字色を赤にする等も効果的です。
    　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

引用返信 [メール受信/OFF] 削除キー/
■15169 / ResNo.7) 　Re[3]: 制約について
□投稿者/ ジェダイの桐 -(2025/10/31(Fri) 09:25:46)
    2025/10/31(Fri) 09:30:29 編集(投稿者)

    ONnojiさん


    おはようございます！


    なるほど。
    errON　の条件選択ですね(^^ゞ

    > 　#cond( (( #is英字( #sstr([機械No],1,1), 1 ) <> 1 ) + ( #is数字( #sstr([機械No], 2, 2), 1 ) <> 1 ) + ( #文字数( [機械No] ) <> 3 ) > 0 ),"背景色'赤'" )

    分解すると、

    #cond(
    (
    ( #is英字( #sstr([機械No], 1, 1), 1 ) <> 1 )
    + ( #is数字( #sstr([機械No], 2, 2), 1 ) <> 1 )
    + ( #文字数( [機械No] ) <> 3 )
    > 0
    ),
    "背景色'赤'"
    )

    こうなります。
    その中の、

    ( #is英字( #sstr([機械No], 1, 1), 1 ) <> 1 )
    + ( #is数字( #sstr([機械No], 2, 2), 1 ) <> 1 )
    + ( #文字数( [機械No] ) <> 3 )
    > 0
    )

    >　そこで、仕方なく　( 条件式 ) + ( 条件式 ) + ( 条件式 ) > 0 と算術的に条件式を作りました。(^^ゞ

    この部分が　論理比較式（ こういう表現でいいのかな？ ）になっているんですね。

    これは根本解決ですね(^^ゞ

    勉強になりました。

    ありがとうございますm(__)m



引用返信 [メール受信/OFF] 削除キー/
■15170 / ResNo.8) 　Re[4]: 制約について
□投稿者/ ONnoji -(2025/10/31(Fri) 09:35:09)
    2025/10/31(Fri) 09:47:18 編集(投稿者)

    > >　そこで、仕方なく　( 条件式 ) + ( 条件式 ) + ( 条件式 ) > 0 と算術的に条件式を作りました。(^^ゞ
    > この部分が　論理比較式（ こういう表現でいいのかな？ ）になっているんですね。
    > これは根本解決ですね(^^ゞ

    以下をもう一度復習してみてください。アハハハha　(^^ゞ

    桐の釣魚大全のトップ > フォームアプリケーション教書　第２部
    ３０．３　条件式の書き方
    https://silicon7565.cloudfree.jp/guide/guide_Part2.htm#section30

    【転載】

    　　＜桐の論理値＞
    　　桐には項目のデータ型として論理型（Yes/No型）はありません。
    　　項目のデータ型に論理型が無いのですから変数のデータ型にも論理型がありません。
    　　しかし、論理値に相当する値はあるのです。結論から先にいうと次のようになります。

    　　（１）条件式において、未定義値は偽とみなされる。
    　　（２）条件式において、数値型等の０（ゼロ）は偽とみなされる。
    　　（３）それ以外は条件式において真とみなされる。

    　　それでは身近な＃条件選択（ ）関数を例にして論理値を考えてみましょう。

    　　（例）＃条件選択（［性別］＝"１"，"男性"，１，"女性"）

    　　上の例は文字列型項目［性別］の値が"１"の時に"男性"という文字列を返し、そうでない時には"女性"という文字列を返します。
    　　ところで最初の条件式の［性別］＝"１"は直感的に理解できますが、
    　　最後の条件式の数値の１（イチ）に対しては不思議に思った経験のある人が多いだろうと思います。作者もその一人です。
    　　それにしても最後の条件式の数値の１（イチ）とはどういう意味なのでしょうか？
    　　そこでもう一度、論理値のルールを確かめてみることにしましょう。

    　　（１）条件式において、未定義値は偽とみなされる。
    　　（２）条件式において、数値の０（ゼロ）は偽とみなされる。
    　　（３）それ以外は条件式において真とみなされる。

    　　上のルールに照らし合わせると数値の１（イチ）はルールの３番めに該当しますね。
    　　なるほどこれで分かりました。つまり、数値の１（イチ）は常に真と評価される条件式になっていたわけです。
    　　ところで、＃条件選択（ ）関数には多くの「＜条件式＞，＜値＞」の組を作ることが出来ますが、
    　　一般的に最後の条件には常に真と評価される条件式が必要になります。
    　　これはすべての条件式に当てはまらない場合に未定義値が返されることを防ぐためです。
    　　常に真と評価される条件式は恒真式と呼びます。
    　　しかし、どうして恒真式を数値の１（イチ）で表現するのでしょうか。
    　　恒真式になりさえすれば別の値でもかまわないはずですね。
    　　試しに次の実験１のように書いてみても正しく動作します。

    　　■実験１

    　　＃条件選択（［性別］＝"１"，"男性"，８，"女性"）
    　　＃条件選択（［性別］＝"１"，"男性"，−８，"女性"）
    　　＃条件選択（［性別］＝"１"，"男性"，"そうでなければ"，"女性"）

    　　作者の考えではルールの２番めで数値の０（ゼロ）が偽であることから、
    　　真の代表を数値の１（イチ）とするのが桐におけるの恒真式の一般的な書き方だろうと思います。

    　　＜条件式の評価結果を変数に代入する＞
    　　さて、真を数値の１（イチ）にすることには一応の根拠があります。
    　　それは次の実験２を行うとよく分かります。

    　　■実験２

    　　変数宣言　固有，数値｛&gLogical｝
    　　代入　&gLogical ＝ （"あ"＝"い"） ／＊（"あ"＝"い"）は条件式　　　　　 ＊／
    　　確認　＃str（&gLogical）　　　　　／＊　&gLogicalの値は０（ゼロ）です　＊／
    　　代入　&gLogical ＝ （"あ"＜"い"） ／＊（"あ"＜"い"）は条件式　　　　　 ＊／
    　　確認　＃str（&gLogical）　　　　　／＊　&gLogicalの値は１（イチ）です　＊／
    　　条件式の評価結果を変数に代入することは普通しませんので、
    　　実験２を見て変な代入コマンドの使い方だと思われた人も多いと思いますが、
    　　実験２から分かるように桐の場合では条件式の評価結果は数値の０（ゼロ）か１（イチ）になります。
    　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
    　　つまり、条件式の評価結果を変数に代入すると真は１、偽は０となるのです。
    　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    ｐ．ｓ．

    > この部分が　論理比較式（ こういう表現でいいのかな？ ）になっているんですね。

    【算術的な条件式】、または【論理代数的な条件式】というのが適当でしょうね。

    ちなみに、普通の場合には論理演算子( .not　.and　.or )を使うべきですよ。

    普段から【算術的な条件式】、または【論理代数的な条件式】を使っているとプログラミングのスジが悪くなります。
    　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　・・・・・・・・・・・・・・・・・
    余程困った時に限って使用してください。(^^ゞ
    ・・・・・・・・・・・・・・・・・・
引用返信 [メール受信/OFF] 削除キー/
■15171 / ResNo.9) 　Re[5]: 制約について
□投稿者/ ONnoji -(2025/10/31(Fri) 09:58:50)
    2025/10/31(Fri) 10:29:09 編集(投稿者)

    > なお、この条件式は
    >
    > #is英字( #sstr([],1,1),　1 )　<> 1 … 項目値の１文字めから１文字が英字ではない
    > #is数字( #sstr([], 2 ,2), 1 ) <> 1 … 項目値の２文字めから２文字が数字ではない
    > #文字数( [] ) <> 3　　　　　　　　 … 項目値の文字数が３ではない
    >
    > この３つを and で結べばＯＫなのですが、２つの条件の and は正常に動くのですが、なぜか３つの条件だと正しく動きません。※桐10ｓの場合
    >
    > そこで、仕方なく　( 条件式 ) + ( 条件式 ) + ( 条件式 ) > 0 と算術的に条件式を作りました。(^^ゞ

    あらら、

    ×　この３つを and で結べばＯＫなのですが、

    〇　この３つを or　で結べばＯＫなのですが、

    でしたね。

    ド・モルガンの定理というやつでしたね。アハハハha。

    ちなみに、もしも・・・

    　#is英字( #sstr([],1,1),　1 )　= 1 … 項目値の１文字めから１文字が英字ではない
    　#is数字( #sstr([], 2 ,2), 1 ) = 1 … 項目値の２文字めから２文字が数字ではない
    　#文字数( [] ) = 3　　　　　　　　 … 項目値の文字数が３ではない

    これ↑ならばこの３つを and で結べばＯＫでした。


引用返信 [メール受信/OFF] 削除キー/
次のレス10件＞

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

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

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

- Child Tree -
- Antispam Version -