吟味できない重要な入力をどのように検証しますか？
入力を吟味する実用的な方法がないときに、ユーザーが誤った入力セットを作成するのをどのように防ぐのですか？ シーン Visual FoxProで書かれた小さなERPパッケージを変更します。パッケージの一部は、トラックのマニフェストとドライバーが配達ルートに送る請求書を印刷することに関係しています。入力として何も入力されない場合、印刷ルーチンはすべてを印刷しようとするため、高速プリンターで無駄になる大量のプリンター用紙が発生します。 私は、GUIインターフェース要素を書き換える立場になく、フレームワーク、ツールキット、またはその他の外部コードをこの状況で使用するように改造することもできません。理由はオフィスの政治に関連しています。既存のERPフレームワークを上書きできるとは言わないでください。これは私には選択肢がないためです。 問題 ユーザーは、圧力が高く、タイムクリティカルな環境にいます。各プロセスは数分または数秒で測定されます。つまり、処理時間をできるだけ最小限に抑える必要があります。この環境と気が散る可能性があるため、ユーザーはダイアログを頻繁に無視し、[Enter]キーを押すと、フォーカスがフォーム内をすばやく移動し、最終的に入力ダイアログのアクションボタンに移動して、自動印刷がトリガーされます。 。 入力は、日付範囲、ルート範囲、および受注範囲で構成されます。 頻繁なバックプリントが必要なため、日付範囲の入力を「今日の日付」に自動設定することはできません。また、エンドユーザーは真夜中に作業を行います。つまり、日付のロールオーバーは、変更を自動検出するルーチンを装備することなくこれを非現実的にします。 ルートの入力はハードコードできません。また、再印刷が必要なため（上記を参照）、すでに出荷されているルートからそれを推定することはできません。 販売注文の入力は、単一の注文または特定の範囲を印刷する場合にのみ意味があります。 したがって、率直に言って、入力を検証する実用的な方法はありません。 印刷をトリガーするアクションボタンはブロックできません。ユーザーの前にブロッキングダイアログを配置するという提案は無視されます。これがオプションではない理由については、私は自由に議論することはできません。ただし、この概念はサイトの他の場所で（別の視点から）すでに議論されており、拒否されました。 ソフトウェアが機能としてこれに対応する必要があるため、すべての入力が空のときに印刷出力をブロックすることは、設計決定として拒否されました。 ユーザー ユーザーはこれを繰り返さないよう繰り返し求められています。彼らはしばしばこのアドバイスを無視します。この不幸な出来事を引き起こすことは彼らの職長/マネージャーが対処するものではないので、行動を終わらせる圧力はありません。 組織 関係するワークフローには発言権はなく、そのワークフローによって影響を受ける既存のソフトウェアコンポーネントの変更のみです。 提供事業者 ベンダーは、元のソフトウェアベンダーからカスタムインストールとしてパッケージをセカンドソースします。ベンダーは、コードベースへの統合のために、すべてのコード変更をベンダーに送り返すことを要求しています。アーキテクチャに大幅な変更を加えると、広範なカスタマイズが行われるため、バージョンの移行中に将来のコストが増加します。場合によっては、プログラマーは、そのような大きな変更を完全に無視し、好きなように実行することを私に伝えさえしました。 ソフトウェア ソフトウェアの選択やインストールについては言うまでもないので、プラットフォームの変更は問題外です。 ソフトウェアの環境に関しては、印刷される各請求書は単一の呼び出しです。バッチ印刷機能はありません。印刷機能がシステムに統合されている方法（および一部の言語の癖）のため、そのAPIの周りにバッチラッパーを作成することはできません。これに加えて、プログラムのこの部分は、請求書印刷を実行する別のプログラムを呼び出し、次に、請求書を1つ印刷するprint-a-report APIを呼び出します。恐ろしいデザインですね。 入力フォームはフォームヘッダーの奇妙な組み合わせで、入力ボックスはありませんが、他のGUI要素を含めることができます。入力ボックスは実行時に定義されます。 目的 ソフトウェアは、ユーザーが誤ってすべての書類を印刷することを防ぎます。 この問題をどのように解決しますか？