magicにおけるエラーの正解は。

dai

• 2025年09月22日 13:20

皆様、いつもお世話になっております。

私は MagicV9Plus の頃から Magic を使用してシステムを開発してきましたが、レコードメインが廃止されたあたりから、正しいエラー処理の方法が分からないまま現在に至っています。
基本的にはコントロール検証にエラー処理を入れるのだと思っていますが、うまくいかずに悩んでおります。

例えば、条件に Flow('FN') を入れてみたり、フローモードを C、フロー方向を F にするとラインモードで入力エラーが頻発したり、逆にフローモードを S、フロー方向を F にするとクリックではエラーを拾えなかったりと、正直どの設定が正解なのか分からない状況です(正解は時と場合によるかとは思いますが)

皆様は入力エラーや「マスタに存在しない場合」など、どのようにエラー処理を組み込まれているのでしょうか。
ご教授いただけますと幸いです。

• 

  nkmt

  • 2025年09月22日 22:12

  こんにちは。
  V9 Plusの頃までは、エラーの条件に　FLOW('FN') 等を書いておりました。
  
  自分はV10、uniPaaS V1 は未経験ですがuniPaaS V1 Plusからはコントロール検証にエラーを書く事が多いです。
  
  V=項目 C=変更 にエラーを書くのも有りなのかもしれないと思いました。
  （何か変化があったからエラーを表示するとか。）
  
  コントロール検証の場合、学校＝中学生、学年＝４年生といった矛盾チェックも行えるメリットがあると思います。
  
  iPadで画面上部に入力フォームがあり、下半分には項目選択サブフォームを配置する場合は、入力フォーム側のエラーチェックはV=項目 C=変更 を使わないと都合悪くてそうした事もあったように思います。
  
  コントロール検証の場合、そのレコード内で１項目、２項目と進もうとすると全コントロールの検証を行おうとすると思います。
  
  以下の画面は、１行目入力し、２行目にパークし、
  ２行目の行も商品も未入力で１行目をマウスクリックで１行目に戻れています。
  
  基本的にその明細行はエラーが無い状態でなければ、他の行へ移動出来ないような考えで作っています。
  
  私の場合は、マスタのコードに0値は許さない事が多いので最近は担当者マスタ等の戻値変数も用意せずに
  エラー　入力してください　　　V_担当者コード=0　　　　　　　CF
  エラー　マスタがありません　　担当者マスタ_担当者コード=0　CF
  のように省略化しています。
  
  入力してください　とか
  ○○マスタがありません　もメインPGの関数にしてメッセージの統一化も図っています。
• 

  nkmt

  • 2025年09月22日 22:23

  私の書いてある事が誤っている事もあり得ますのでそのつもりでご覧ください。
• 

  Ｐｕ

  • 2025年09月24日 03:04

  こんにちはＰｕです
  私もnkmtさんと同じです。

  でわ～でわ～
• 

  Tanda

  • 2025年09月24日 04:29

  daiさん、

  「マスターに存在しない」の場合は、「照会リンクの戻り値がFalseのとき」という判定で行けますよ。

  入力エラーとはどんなケースですか？Magicの入力チェックに無いようなものですか？たとえば、「9月40日」と入力するとエラーになるという、埋込型の入力チェックです。
• 

  dai

  • 2025年09月24日 04:55

  nkmtさん

  ご丁寧なご回答ありがとうございます。

  やはりV9 Plusまでは FLOW('FN') を使ったエラー記述が一般的だったのですね。
  その後のバージョンからは、やはりコントロール検証にまとめるのが基本とのこと、大変参考になりました。

  自分の環境では、ラインモードでの逐次チェックがどうしても煩雑になりがちで悩んでいたので、
  「基本的に明細行はエラーがあれば他行に移動できない」という考え方をベースに組み直してみようと思います。

  貴重な経験談を共有いただき、本当にありがとうございました。

  Ｐｕさん
  同意との意見も大変参考になります。ありがとうございます。
• 

  dai

  • 2025年09月24日 05:13

  Tandaさん

  エラーについて悩んでいたのは、売上入力の際の処理がきっかけでした。
  商品検索画面にチェックボックスを設け、複数商品を選択して画面を閉じると、選択した商品を一括で売上明細に書き込むようにしているのですが、その処理の途中でコントロール検証に引っかかってエラーが出てしまうことがありました。
  その経験から、「エラー処理の正解は一体何なのだろう？」と考えるようになったのが発端です。

  売上入力に機能を追加していくうちに処理が複雑になり、コントロール検証や「V=項目、C=変更」を経由してしまうことで、全体としてどうしてもスッキリしない印象になってしまいました。「V=項目、C=変更」に関してはパラメータを作成すれば対応できるかと思いますが、そもそも自分のエラー処理に対する認識が皆様と合っているのかどうかを確認したく、今回ご質問させていただきました。
• 

  nkmt

  • 2025年09月24日 05:42

  daiさん　こんにちは。
  （私は結局お客様リリースには至っておりませんし、本題から逸れてしまいますが・・・）
  売上伝票入力の明細で商品検索画面を表示し、商品検索画面でこれとこれとこれのように複数選択した場合は、売上伝票入力画面側のサブタスク側で売上明細データに複数レコードをINSERTして、ビュー再表示するプログラムをリリース可能レベルまで作りましたが、リリースには至っておりません。
  
  V=項目、C=変更は手動変更かそうでないか・・・の判断はよく使っております。
• 

  dai

  • 2025年09月24日 09:41

  nkmtさん

  複数選択はユーザーにとって便利だと思いますが、作成する側としては大変ですよね。
  サブタスクで複数レコードをINSERTする際に、コントロール検証に引っかかったり、変数がデータビューの一部となっていることに気付かず、ビュー再表示で新規レコードが先に作成され、インデックスの重複によりINSERTできなかったりと、さまざまな試行錯誤を行いましたが何とか形にはなっているようです。

  脱線してしまいましたが、これ以外にもお聞きしたいことがありますので、また改めて質問させていただきます。
  ありがとうございます。
• 

  Tanda

  • 2025年09月25日 02:33

  daiさん、

  Flow() 関数はまだこの世にマウスが存在しなかった頃のMS-DOS時代の名残りでして、キーボード操作によって次項目に進むか、前項目に戻るかが処理の基準になっていました。

  その後、MagicもWindows対応になり、マウス操作が入って以降は、好きな項目をクリックして、どこにでもジャンプできるようになりましたので、これに対応するために、「コントロール後処理」や「コントロール検証」とかが登場して進化してきたわけです。

  エラー処理を行う場合も、この違いを意識してコーディングすれば、きっと参考になるかと思いますよ。
• 

  dai

  • 2025年09月26日 22:27

  Tandaさん

  なるほど、Windows対応でマウス操作が加わったことで、処理の流れやエラー対応の考え方が大きく変わったんですね。
  どこでもクリックできる前提がある分、エラー処理については常に悩まされます。エンドユーザーはこちらの想定を超える使い方をすることも多いので、できるだけ柔軟に受け止めつつ、システムとして破綻しない仕組みを用意する必要があると感じています。
  とても参考になりました。ありがとうございます。
• 

  nkmt

  • 2025年09月29日 01:47

  daiさん　こんにちは。
  Webの入力画面は、入力途中ではエラーチェックをしない画面が多いですよね。
  クラサバ等のシステムも今その項目は入力出来ないけど、先に入力を進めて最後に必須チェックを行うとか、そんな作りも有りなのでしょうね。
  自分の場合はほとんどしてませんけど。

サインインしてコメントを残してください。