vb.net - 複数のフォームを使用する場合のベスト プラクティス - vb.net

Question

Visual Basic プログラムでさまざまなメニュー/画面/フォームを使用するためのベスト プラクティスは何ですか? 必要なメニューまたは画面ごとに新しいフォームを作成するだけですか? または、他のより良いオプションはありますか？

これを過度に複雑にしようとしているわけではありません。取り組むべきグループ プロジェクトがあり、全員がさまざまなスキル レベルを持っています。そうは言っても、私の好奇心はピークに達しているので、始める前に聞いても害はないと思いました.

Answer 1

私の場合、複数のフォームを扱うときはMDI Parent Form、Windowsのタスクバーで複数の項目を避けるために使用します。

もう1つの珍しい解決策は、各フォームShowInTaskbarプロパティをfalseに設定することです。

Answer 2

この質問は、オープンエンドすぎるため、すぐに閉じられていることがわかります。それが起こる前に、これについて私の重要な不満を述べさせてください... TabControlページの.Visibleプロパティはありませんか? まじで、マイクロソフト??

これが重要なポイントにつながります。フォームが何らかの形で関連しているが、必ずしも同一であるとは限らない場合、コントロールの明らかな欠点にもかかわらず、異なるタブを持つ単一のフォームを使用することを好みます。(SO での回避策を見つけるために遠くを探す必要はありませんが、回避策は依然として回避策です。) 実行時にコントロールを動的に操作することは、このコインのもう 1 つの側面ですが、私が使用することはめったにありません.. . しかし、それは単なる個人的なことです.

たとえば、最近のアプリケーションでは、いくつかのタイプのオブジェクトのリストがありました。それらは関連していましたが、まったく異なる機能を実行し、ユーザーは一度に複数のリストを見る必要はありませんでした。その結果、オブジェクト リストごとに 1 つのタブを備えた 1 つのフォームを使用して、ユーザーの表示が乱雑にならないようにしました。

同様に、最近 GL アプリを作成したとき、ジャーナル ヘッダーとジャーナル ライン エントリ (バックエンド データベースの別のテーブルに移動する) を 1 つのフォームの別々の部分にしました。一方、アセットの作成はかなり異なっていたので、作成プロセスで基礎となるデータの一部が共有されていたにもかかわらず、別のフォームを作成しました。(つまり、仕訳明細データです。)

私は「ベスト プラクティス」という概念を信じていません。ただし、私が使用する「経験則」は次のとおりです。 7 つの異なる役割を実行する 1 つのフォームを維持しようとすると、狂気とフラストレーションへの道が保証されます。

はい、2 つのルールは矛盾していますが、ある意味で、設計のこの側面はデータベースの正規化に似ていると考えています。過度の正規化 (ディスプレイごとに個別の形式) と不十分な正規化 (あまりにも多くの無関係な機能を 1 つの形式に押し込もうとする) の間には、スイート スポットがあります。少なくとも、ルールは常に「このフォームが必要なのか、それとも私がすでに行ったことと関係があるのか​​?」と考えるための一時停止を与えてくれます。

経験則の 3 つ目は、明らかに... 常にユーザーの視点から見ることです。彼らはあなたが彼らを振り回しすぎているように感じるでしょうか？すべてのフォームがルック アンド フィールを共有しているか、さらに重要なこととして、何かを見つける場所を常に把握できるようにレイアウトを制御しているか。

これらはすべてアプリごとに異なり、すべての私見に適合する 1 つのサイズはありません。