2009-04-21 15 views
3

私は、CompactFramework 2.0をターゲットとし、C#でコーディングするWindows Mobile用のWinFormsベースのアプリケーションを作成しています。CompactFramework 2.0 - フォームとパネルへのローリングの組み合わせ

私のアプリケーションには、ユーザーが厳しい職務を選択できるメニューがあります。メインフォームの上に新しいフォームを開くために良い仕事特定の画面については

は、私がメインフォームでパネルにユーザーコントロールをロードする必要があり、またはそれは次のとおりです。

私の質問はこれですか?

どちらも私のニーズを満たしているようですが、ここに「正しい」答えがあるかどうかはわかりません。

もう一方の方法が正しいですか?

答えて

2

フォームはコントロールです(継承チェーンを見れば分かります)。フォーム自体はオーバーヘッドがあまりありません。これはネイティブウィンドウを作成しますが、それはそれです。

ソリューションにUI要素をどのように使用して表示するかは、どのような決定要因になりますか。フォームは多くのUIアーキテクチャーに役立ち、ほとんどの開発者がよく知っているものです。デザイナーはそれらをうまくサポートし、フォームを作成、表示、隠し、閉じていることはよく文書化されていてよく使われるパラダイムです。はい、それは含まれているコントロールのすべてを作成するようにフォームが作成されるたびに負荷のペナルティがありますが、UserControlの場合でもそれを支払うつもりです。どちらの場合でも子コントロールを作成する必要があります。

フォームでは毎回フォームを作成する必要がありますが、それは当てはまりません。 Closeの代わりにShowDialogまたはHideを使用すると、フォームを再利用して価格を一度支払うことができます。ここでの利点は、フォームがあなたのコントロールをあなたのために保持し、あなたのためにそのすべてを管理するので、GCを気にする必要がほとんどなく、生きている根を思い出すことです。

UserControlのパラダイムはより複雑です。メモリの負荷を低く抑えるために、自分でコントロールのロードとアンロードを管理する必要があります。複雑さはまた、維持コスト、サポートコスト、および開発コストの増加を招く。しかし、いくつかのシナリオでもUserControlsには明確な利点がいくつかあります。 MVC/MVPパターンとビューを扱うフレームワークを使用すると、USerControlはフォームがワークスペースになっている実際のビューを作成します(SCSF for the desktopはこれの古典的な例であり、OpenNETCF.IoC frameworkもCF用です)。

「これは良い」ですか?それは要素の使用方法と場所、チームがすでに開発を行っている方法、接続しているソリューションをどのように構築したかによって異なります。一言で言えば、正解は誰もいません。

0

フォーム/コントロールの複雑さによって異なります。 UserControlルートを使用すると、処理するフォーム作成機能をすべて持たないため、パフォーマンスが向上します。

2

私の経験では、ハードウェアによっては、別のフォームを起動するよりもはるかに優れています。私たちのデバイス(32メガワットのMotorola WT4090)はハードウェアアクセラレーションを持っていません。フォームが起動されるたびに、4〜6秒の遅延があります。しかし、コントロールはほとんど瞬間的です。

+0

ことがあるかもしれない理由はわかりません。フォームはコントロールから派生し、そのためにコントロール自体があります。それは単なるコンテナコントロールです。それは含まれている子供が建設中に多くの仕事をしない限り、それは実際にはほとんどオーバーヘッドを持っていません(それはフォームの誤りではありません)。 – ctacke

+0

@ctacke私は何か非常に間違っていると言っているわけではありませんが、単純なテキストボックスを使ってForms vs. Controlsを使って比較しようとしました。同様の結果。具体的には、私たちのデバイスでは、previoiusフォームをクリアして、新しい完全なフォームを表示することに問題があるようです。私は、デバイスがはるかに小さな矩形を描画するだけで、以前のものを処分する必要がないため、速度が向上したと推測しました。しかし、純粋に推測する。 –

0

私のアドバイスは、異なる論理アクションごとに新しいWindowsフォームを作成することです。論理的に独立したフォームが必要な場合は、個別のWindowsフォームを用意する方がよいでしょう。

高速化するために、アプリケーションの起動時にすべてのフォームを構築できます。これにより、アプリケーションの起動時に遅延が発生します(ほとんどのユーザーはこれで問題ありません)が、その後はすべてが高速に実行されます。

1

多分、最良の答えは、一連のユーザーコントロールを作成し、メインフォームにそれらを読み込むことです。パフォーマンスを向上させることができるかどうかを確認するためのユーザーコントロールだけを持つ一連のフォームを作成しようとすると、かなり簡単に問題になるはずです。

いずれの方法でもパフォーマンス上のメリットが見られない場合は、それは単なる問題のようです。

1

フォームを使用します。これは、他のアプリケーションが動作する方法です。これは、ユーザーがアプリケーションを動作させる方法です。

プリインストールされた「連絡先」アプリケーションを確認します。起動時に連絡先リストが表示されます。連絡先を選択すると、新しいフォームが現在のウィンドウの上に開かれます。すべての連絡先の詳細を表示しています。メニューから「編集」を選択すると、別のフォームが開き、連絡先を編集できます。 「タスク」アプリケーションはまったく同じように動作します。

ユーザーは知っている:どこかをクリックすると新しいフォームが開き、そのフォームを閉じると最後のフォームに戻る。あなたはそれに反するよりもむしろその知識と一緒に働くべきです。単一のフォームを使用すると、ユーザーは実際に最後のフォームに戻ろうとしている間に繰り返し閉じることがあります。

パフォーマンスの観点からは、私のWM 5と私のWM 6デバイスで十分に速い(< 1秒)フォームが開いていることがわかります。

UserControlsでフォームのような動作を実現することは可能ですが、フォームのような動作が必要な場合はフォームを使用する方がはるかにストレートです。

私の結論は次のとおりです。フォームを使用してください!

P.S:上CodeProjectの上で良い記事があります:How to create MDI Application in Compact framework

+0

UserControlsを使用しても、同じ動作が実現できます。 Formsでのプログラミングに慣れているので、Formsの動作のように見えますが、実際に実装されていることを意味するわけではありません。 – ctacke

+0

@ctake:それを指摘してくれてありがとう。私はそれに応じて投稿を編集した。 –

関連する問題