8

マルチドキュメントアプリケーションを開発しています。現在、(開発者としての) 私にとって非常に便利な MDI を使用しているだけでなく、ユーザーにとっても非常に便利です。ただし、「反対」が1つあります-多くの子ウィンドウをすばやくロードする解決策が見つかりませんでした（ウィンドウが作成され、親の領域を埋めるために最大化されるたびに、サイズ変更の「アニメーション」があり、多くの時間がかかります）これまでのところ、タブ付きのインターフェイスに戻すことを検討しています（これにはさらに作業が必要です。フォームをページシートに「埋め込む」必要があります。利用可能なフォームには多くの「種類」があり、テキストドキュメントを編集するためのものもあります） 、他のオブジェクト用のものもあります)...

それで、あなたの意見は何ですか？MDI またはタブ付きインターフェースを使用する必要がありますか?

4

4 に答える 4

11

新しい MDI 子ウィンドウのサイズ変更アニメーション (および遅延) を回避するには、子ウィンドウを作成する前に親 TForm の ClientHandle プロパティに WM_SETREDRAW メッセージを送信し、完了したら再度送信します。

Self.Perform(WM_SETREDRAW, False, 0);
... create child windows as needed ...
Self.Perform(WM_SETREDRAW, True, 0);
Windows.InvalidateRect(Self.ClientHandle, nil, True);
Windows.UpdateWindow(Self.ClientHandle);
于 2009-09-23T00:16:48.810 に答える
10

MDI は Windows 3 の時代 (またはそれ以前?) に開発されたもので、最近では十分にサポートされていません。フォームが異なる複数のドキュメントが必要な場合は、タブ付きのインターフェイスを使用することをお勧めします。フォームの代わりにフレームを使用し、新しいタブを作成してその上にフレームを配置し、alClient に合わせます。

于 2009-09-23T00:07:18.580 に答える
5

あなたが引用したものよりも、MDIには確かに多くのマイナス点があります. これに関する議論は、ウィキペディアや、Windows インターフェイス ガイドラインでも見つけることができます。MDI は何年も前から廃止されています。Microsoft 自体は、もはやどの大規模アプリケーションにも MDI を「標準」形式で使用しておらず、多くの場合、他の UI スタイルと一緒に MDI エミュレーションのみを提供しています。

プログラムが複数の画面を持つユーザー向けである場合、MDI とタブベースの UI の両方に、ドキュメント ウィンドウが親ウィンドウの内側に制限されるという問題があります。

アプリケーションを適切に設計すれば、MDI とタブベースの UI のどちらにするかを実際に決める必要はありません。どの UI が最も快適で、どの UI が自分の作業スタイルに最も適しているかをユーザーが判断できるようにします。複数の独立した最上位ドキュメント ウィンドウ (1 つのアプリケーション インスタンスまたは複数) も許可します。ドキュメントのフレーム クラスを作成し、それらをタブ コントロール、MDI 子ウィンドウ、またはトップレベル ウィンドウのいずれに埋め込むかを実行時に決定するのと同じくらい簡単です。

于 2009-09-23T04:17:51.053 に答える
3

質問: ユーザーが一度に複数の埋め込みフォームまたはフレームを表示できることは重要ですか? そうでない場合は、必ずタブに移動してください。

タブを使用すると、ナビゲートしやすく、利用可能なものを簡単に確認できます。しかし、標準の PageControl では、一度に 1 つのタブしか表示できません。「タイリング」や「カスケード」はありません。問題は、たとえば、ユーザーがあるタブから別のタブにドラッグする必要がある場合に始まります。もちろん、それは可能ですが、それほど便利ではありません。なぜなら、今回はユーザーが何かをどこにドラッグしているのかわからないからです。

この制限を克服するには、ドッキング UI を検討する必要があります。これにより、複雑さが増しますが、タブを表示したり、並べて表示したりできます。

于 2009-09-23T01:03:48.140 に答える