タグ付けされた質問 「winforms」

プロジェクトを整理する特定のスタイルはありますか？ たとえば、現在ボリビアのいくつかの学校でプロジェクトを作成していますが、これが私がそれを整理した方法です。 TutoMentor (Solution) TutoMentor.UI (Winforms project) TutoMentor.Data (Class library project) プロジェクトをどのように整理しますか？あなたが組織し、誇りに思っているものの例はありますか？ソリューションペインのスクリーンショットを共有できますか？ 私のアプリケーションのUI領域では、さまざまなフォームとそれらが属する場所を整理するための適切なスキーマを決定するのに苦労しています。 編集： .UIプロジェクトでさまざまなフォームを整理するのはどうですか？どこで/どのように異なるフォームをグループ化する必要がありますか？それらをすべてプロジェクトのルートレベルに配置するのは悪い考えです。

148 c#  .net  winforms  code-organization 

私はWPFとWinFormsの主要なスレッドのほとんどを読みましたが、試行されたものと真の以前の技術（Winforms）と、その後継者（WPF）を決定するときに陥りがちな不幸なアンビバレンスに陥りました。 私は長年にわたりベテランのDelphiプログラマであり、ついにC＃へのジャンプを始めています。Delphiの仲間であるDelphiプログラマーは、Delphiで有名なAnders HejlsbergがC＃の設計者であることを知って興奮していることを理解します。DelphiのVCLカスタムコンポーネント、特にマルチコンポーネントウィザードや子コンポーネントのコンテナとして機能するコンポーネントの作成に関与するコンポーネントには強い依存症があります。 その背景から、DelphiからC＃に切り替えた皆さんが、私の最初のアプリケーションを作成するためのWinFormsとWPFの決定に役立つことを願っています。コーディングや、完全なオートコンプリートや適切なデバッガーサポートなどによってAPIの機能や呼び出しに関する情報がすぐに見つかるなど、バグの回避策を見つけることができるので、私は非常に焦ります。 。 2009年初頭のSOスレッドとコメントは、C＃UI開発コーディングを損なう可能性のあるフラストレーションの可能性に関して、WPFに大きな懸念を示しています。一方で、放棄されていなくてもすぐに交換される（WinForms）API技術を学ぶのに膨大な時間を費やすことは、同様に厄介であり、WPFの食欲をそそるGPUサポートを見つけます。 したがって、私のアンビバレンス。私はどちらの技術もまだ習得していないので、新たなスタートを切るまれな機会があり、大きな「未学習」曲線に直面する必要はありません。一方、WPFの使用がイライラしたり、私のような短気なRAD開発者に他の大きなマイナスの結果をもたらす場合は、WPFが同じレベルのサポートと使いやすさを達成するまでWinFormsを使い続けます。プログラマーとしての私の心理を具体的に示すために、私はVBを使用し、その後Delphiを使用して、初期のWindowsアプリの開発中に多くの開発者が苦労したWindows UIライブラリであるMFCによるコーディングの非常に大きな痛みを完全に回避しました。MFCを回避できたことを後悔したことはありません。 Anders HejlsbergがWPFおよび/またはWinFormsのアーキテクチャに手を携えているかどうか、そしてどちらかのコードベースで具体化された創造的なビジョンと使いやすさに不一致があるかどうかを知ることも安心です。最後に、Delphiプログラマーのために、WinFormsとは対照的にWPFを使用するとき、特にデバッガーのサポートに関して、「IDEショック」がどれだけ必要かを教えてください。2011年に更新された求人市場のコメントも歓迎します。

38 c#  wpf  winforms  delphi  microsoft 

少し前にwinformアプリケーションの作成を開始しましたが、その時点ではそれは小さく、プロジェクトの構成方法については何も考えていませんでした。 それ以来、必要に応じて追加の機能を追加し、プロジェクトフォルダーはどんどん大きくなっています。今では、何らかの方法でプロジェクトを構成する時が来たと思いますが、適切な方法はわからないので、質問はほとんどありません。 プロジェクトフォルダを適切に再構築する方法は？ 現時点では、次のようなことを考えています。 フォーム用のフォルダーを作成する ユーティリティクラスのフォルダーを作成する データのみを含むクラスのフォルダーを作成する クラスを追加するときの命名規則は何ですか？ クラスの名前を見るだけで機能を識別できるように、クラスの名前も変更する必要がありますか？たとえば、すべてのフォームクラスの名前を変更して、名前がFormで終わるようにします。または、それらのための特別なフォルダが作成されている場合、これは不要ですか？ メインフォームのすべてのコードがForm1.csに収まらないようにするため 私が遭遇した別の問題は、追加する各機能でメインフォームがより大きくなっているため、コードファイル（Form1.cs）が非常に大きくなっていることです。たとえば、TabControlがあり、各タブには多数のコントロールがあり、すべてのコードはForm1.csになりました。これを避ける方法は？ また、これらの問題を扱っている記事や本を知っていますか？

26 .net  visual-studio  winforms  project-structure 

私は長年Windows Forms開発者を経験していましたが、新しいWPFプロジェクトが間もなくやってくるので、WPFに移行する時が来ました。 Winformsの経験豊富な開発者にとって最善の方法は何ですか？ 短時間でWPFを学習するためのヒントや推奨事項を教えてください。 簡単なサンプルWPFソリューションと短い（ビデオ）チュートリアルはありますか？どの本をお勧めしますか？www.windowsclient.netは良い出発点ですか？公式のMicrosoftサイトに代わるものはありますか？

26 c#  .net  windows  wpf  winforms 

アイテム番号のUPCを計算するために、Windowsフォームで作業しています。 一度に1つのアイテム番号/ UPCを処理するものを正常に作成しました。次に、複数のアイテム番号/ UPCに対して拡張および実行したいと思います。 リストを使い始めてみましたが、行き詰まってしまいます。ヘルパークラスを作成しました。 public class Codes { private string incrementedNumber; private string checkDigit; private string wholeNumber; private string wholeCodeNumber; private string itemNumber; public Codes(string itemNumber, string incrementedNumber, string checkDigit, string wholeNumber, string wholeCodeNumber) { this.incrementedNumber = incrementedNumber; this.checkDigit = checkDigit; this.wholeNumber = wholeNumber; this.wholeCodeNumber = wholeCodeNumber; this.itemNumber = …

22 c#  array  winforms  list 

過去に、アプリケーションでWindowsフォームの拡張を許可するために継承を使用しました。すべてのフォームに共通のコントロール、アートワーク、および機能がある場合、共通のコントロールと機能を実装する基本フォームを作成し、他のコントロールがその基本フォームから継承できるようにします。ただし、その設計にはいくつかの問題があります。 コントロールは一度に1つのコンテナにしか入れることができないため、静的なコントロールは扱いにくいものになります。たとえば、このクラスの他の（派生）インスタンスがすべて同じTreeViewを変更および表示できるように、保護および静的にするTreeViewを含むBaseFormというベースフォームがあるとします。TreeViewは一度に1つのコンテナにしか入れることができないため、これはBaseFormから継承する複数のクラスでは機能しません。おそらく初期化された最後のフォームにあります。すべてのインスタンスはコントロールを編集できますが、一度に1つだけ表示されます。もちろん、回避策はありますが、それらはすべていものです。（これは私にとって本当に悪い設計のようです。なぜ複数のコンテナが同じオブジェクトへのポインタを格納できないのでしょうか？とにかく、それがそうです。） フォーム間の状態、つまり、ボタンの状態、ラベルテキストなど、グローバル変数を使用して、Loadの状態をリセットする必要があります。 これは、Visual Studioのデザイナーによって実際にサポートされていません。 使用するのに優れた、それでも簡単に保守可能な設計はありますか？または、フォームの継承が依然として最善のアプローチですか？ 更新 MVCからMVPに、オブザーバーパターンからイベントパターンに移動しました。ここに私が今考えているものがあります、批評してください： BaseFormクラスには、コントロールと、それらのコントロールに接続されたイベントのみが含まれます。それらを処理するために何らかのロジックが必要なすべてのイベントは、すぐにBaseFormPresenterクラスに渡されます。このクラスは、UIからのデータを処理し、論理演算を実行してから、BaseFormModelを更新します。モデルは、状態の変更時に発生するイベントをPresenterクラスに公開し、Presenterクラスはサブスクライブ（または監視）します。プレゼンターはイベント通知を受け取ると、ロジックを実行し、それに応じてビューを変更します。 メモリには各Modelクラスが1つしかありませんが、BaseFormの多くのインスタンス、したがってBaseFormPresenterが存在する可能性があります。これにより、BaseFormの各インスタンスを同じデータモデルに同期するという私の問題が解決します。 質問： どのレイヤーが最後に押されたボタンのようなものを保存する必要があるので、フォーム間でユーザーのために強調表示し続けることができます（CSSメニューのように）？ このデザインを批判してください。ご協力いただきありがとうございます！

20 c#  .net  object-oriented-design  inheritance  winforms 

ビューをロジックから分離するMVCのようなパターンがあることは知っていますが、Winformアプリケーションでそれらがどれほど一般的かはわかりません。 C＃Winformアプリケーションの場合、a Formから始めてUIコンポーネントを徐々に追加し、コンポーネントのイベントに対して（click、textchanged...）関数を呼び出すか、ロジックを直接記述します！ 私はそれが悪い習慣であることは知っていますが、Visual Studioでそのようなプロジェクト（テンプレート、フレームワーク、開始点）を開始する最善の方法は何なのかわかりません。MVCが唯一の解決策ですか？私はどんなプロジェクトでもそれをすべきですか？！ 開始するためのガイドラインまたは軽量フレームワークを受け取りたいです。

18 c#  mvc  winforms 

私は過去にMVPとMVCを使用しましたが、MVPのほうが実行の流れを非常によく制御できるので、私の意見ではMVPを好んでいます。 インフラストラクチャ（データストア/リポジトリクラス）を作成し、サンプルデータをハードコーディングするときに問題なく使用できるので、GUIに移行してMVPを準備しています。 セクションA エントリポイントとしてビューを使用するMVPを見ました。つまり、ビューコンストラクターメソッドでプレゼンターを作成し、次にプレゼンターがモデルを作成し、必要に応じてイベントを関連付けます。 プレゼンターは、ビュー、モデル、プレゼンターが作成されるエントリポイントとしても見てきました。このプレゼンターには、コンストラクターでビューとモデルオブジェクトが与えられ、イベントを結び付けます。 2と同じですが、モデルはプレゼンターに渡されません。代わりに、モデルはメソッドが呼び出され、応答が直接返される静的クラスです。 セクションB 私が見たビューとモデルの同期を保つという点で。 ビューの値が変更されたとき、つまりTextChanged.Net / C＃のイベントが発生したとき。これDataChangedEventにより、モデルに渡されるa が起動され、常に同期が保たれます。そして、モデルが変化する場所、つまり、モデルがリッスンするバックグラウンドイベントの場合、ビューはを上げるという同じアイデアによって更新されDataChangedEventます。ユーザーが変更をコミットSaveEventしようとすると、モデルが起動して保存されます。この場合、モデルはビューのデータを模倣し、アクションを処理します。 ＃b1と同様ですが、ビューは常にモデルと同期しません。代わりに、ユーザーが変更をコミットしたい場合に起動SaveEventされ、プレゼンターは最新の詳細を取得してモデルに渡します。この場合、モデルは、それに基づいて行動する必要があるまでビューデータを認識しません。その場合、必要なすべての詳細が渡されます。 セクションC ビュー内のビジネスオブジェクト、つまりプリミティブデータ（int、double）ではなくオブジェクト（MyClass）の表示 ビューには、ドメイン/ビジネスオブジェクトとして表示されるすべてのデータのプロパティフィールドがあります。ビューはこれらをTreeViewのノードに処理しますが、プロパティをview.Animals公開するなどIEnumerable<IAnimal>。次に、選択した動物について、プロパティSelectedAnimalとして公開しIAnimalます。 ビューはドメインオブジェクトの知識を持たず、プリミティブ/フレームワーク（.Net / Java）に含まれるオブジェクトタイプのみのプロパティを公開します。この場合、プレゼンターはアダプターオブジェクトにドメインオブジェクトを渡し、アダプターは特定のビジネスオブジェクトをビューに表示されるコントロールに変換します。この場合、アダプターは、ビューだけでなく、ビューの実際のコントロールにアクセスできる必要があるため、より緊密に結合されます。 セクションD 単一のコントロールを作成するために使用される複数のビュー。つまり、さまざまなタイプのオブジェクトを保存するような単純なモデルを持つ複雑なビューがあります。適切なコントロールが表示される項目をクリックするたびに、メニューシステムを横に配置できます。 ビューインターフェイスを介して公開される個々のコントロールすべてを含む1つの巨大なビューを作成します。 いくつかのビューがあります。メニュー用のビューとブランクパネルが1つあります。このビューは、必要な他のビューを作成しますが、表示しません（visible = false）。このビューは、含まれる各ビュー（子ビュー）のインターフェイスも実装するため、1人のプレゼンターに公開できます。空白のパネルには、他のビュー（Controls.Add(myview)）および（(myview.visible = true）が表示されます。これらの「子」ビューで発生したイベントは、親ビューによって処理されます。親ビューは、イベントをプレゼンターに渡し、逆もまた同様です。 メインビューであれ小さなビューであれ、それぞれのビューは、それぞれ独自のプレゼンターとモデルに配線されます。ビューコントロールを既存のフォームに文字通りドロップするだけで、機能の準備が整い、舞台裏でプレゼンターに配線するだけで済みます。 セクションE すべてにインターフェースがある場合、上記の例でMVPがどのように行われるかに基づいて、相互互換性がない可能性があるため、この回答に影響します。 すべてには、View、Presenter、Modelというインターフェースがあります。これらのそれぞれは、明らかに具体的な実装を持っています。具体的なビューが1つしかない場合でも、モデルとプレゼンター。 ビューとモデルにはインターフェースがあります。これにより、ビューとモデルが異なります。プレゼンターは、ビューおよびモデルオブジェクトを作成/指定され、それらの間でメッセージを渡すだけです。 ビューのみにインターフェースがあります。モデルには静的メソッドがあり、作成されないため、インターフェースは不要です。別のモデルが必要な場合、プレゼンターは静的クラスメソッドの別のセットを呼び出します。モデルは静的であるため、プレゼンターへのリンクはありません。 個人的な考え 私が提示したすべての異なるバリエーション（ほとんどはおそらく何らかの形で使用しました）から、さらに多くのバリエーションがあると確信しています。A3は、MVPの外でビジネスロジックを再利用可能に保つこと、A2はデータの重複を減らし、発生するイベントを減らすことを好みます。C1は別のクラスに追加しないため、少量のユニットテスト不可能なロジックをビューに入れます（ドメインオブジェクトの視覚化方法）が、これはコードレビューするか、アプリケーションで単に表示することができます。ロジックが複雑な場合、アダプタークラスに同意しますが、すべての場合に同意するわけではありません。セクションDの場合、D1はメニューの例としては大きすぎるビューを作成すると感じています。以前にD2とD3を使用しました。D2の問題は、イベントをプレゼンターとの間で適切な子ビューにルーティングするために大量のコードを記述する必要があり、ドラッグ/ドロップ互換性がないことです。新しいコントロールごとに、単一のプレゼンターをサポートするためにより多くの配線が必要です。D3は私の好みの選択肢ですが、ビューが非常に単純であるか、再利用する必要がない場合でも、ビューを処理するプレゼンターおよびモデルとしてさらに多くのクラスを追加します。D2とD3の混合物は、状況に基づいて最適だと思います。セクションEに関しては、インターフェースを持つものはすべてやりすぎだと思うので、ドメイン/ビジネスオブジェクトに対しては既にそれを行っており、そうすることで「デザイン」に利点がないことがよくありますが、テストでオブジェクトをモックするのに役立ちます。個人的には、E2を古典的なソリューションと考えていますが、E3は以前に取り組んだ2つのプロジェクトで使用されています。D2とD3の混合物は、状況に基づいて最適だと思います。セクションEに関しては、インターフェースを持つものはすべてやりすぎだと思うので、ドメイン/ビジネスオブジェクトに対しては既にそれを行っており、そうすることで「デザイン」に利点がないことがよくありますが、テストでオブジェクトをモックするのに役立ちます。個人的には、E2を古典的なソリューションと考えていますが、E3は以前に取り組んだ2つのプロジェクトで使用されています。D2とD3の混合物は、状況に基づいて最適だと思います。セクションEに関しては、インターフェースを持つものはすべてやりすぎだと思うので、ドメイン/ビジネスオブジェクトに対しては既にそれを行っており、そうすることで「デザイン」に利点がないことがよくありますが、テストでオブジェクトをモックするのに役立ちます。個人的には、E2を古典的なソリューションと考えていますが、E3は以前に取り組んだ2つのプロジェクトで使用されています。 質問 MVPを正しく実装していますか？適切な方法はありますか？ バリエーションのあるマーティン・ファウラーの作品を読んだことがあり、MVCを始めたとき、コンセプトを理解していましたが、エントリポイントがどこにあるのか、すべてが独自の機能を持っていますが、オリジナルを制御して作成するものは元々理解できませんでしたMVCオブジェクトのセット。

14 c#  design  design-patterns  winforms 

私はそれ以来、MVCパターンを使用してGUIを設計しているC ++開発者です。 最近、C＃に戻りたいと思い、Windowsフォームアプリケーションをセットアップしましたが、MVC準拠の構造にプッシュする方法が少し失われました。 私が現在やろうとしていることは、WinFormsに与えられたクラスをビューとして「宣言」し、モデルとコントローラーのクラスをバックグラウンドで追加することです。ただし、ボタンのクリックなど、イベントと対話する方法についてはよくわかりません。通常、これらのイベントをコントローラーにリダイレクトし、完了したらビューでアクションを実行します。 しかし、これはこの星座ではかなり不満を感じます。たとえば、「Exit」ボタンを実装する場合、ViewからControllerにイベントをリダイレクトする必要があります。また、Viewに追加のパブリックメソッドを実装し、それをControllerから呼び出すことができます。最初のインスタンスのViewからClose（）を呼び出すだけです。 何かアドバイスはありますか？C＃でのWindows Formsの私の理解は、MVC実装を試すにはまだ十分ではありませんか？フォームクラスに間違った役割を与えていますか？MVCはこのユースケースにとって単に不適切なアーキテクチャですか？

11 c#  mvc  winforms 

複数の「スクリーン」を持つWinformアプリを構築する適切な方法は何ですか？たとえば、小さなバックアッププログラム（主に笑い用）を作成しようとしていますが、コントロールとコンテナーをフォームにダンプしています。 パネルとグループボックスを使用して異なる画面を分離しています（例：パネルを使用して[設定]ウィンドウのすべてのコントロールを保持し、別のパネルを使用して設定済みのすべての現在のバックアップを表示しています）。まあ、私のform.csファイルは膨大な量のコードに膨れ上がり、何か間違ったことをしているように感じます。ファイルにはほとんど何も見つかりません。最初からやり直す準備ができています。このプロジェクトは、私にとってC＃と.NETの知識を広げるためだけのものでした。そのため、新しいプロジェクトを開始することは大したことではありません。

11 c#  gui  winforms  gui-design 

VB4を学び、ボタンをフォームにドラッグし、そのボタンをダブルクリックし、魔法のように恵まれたイベントハンドラーにコードを入力したことを覚えています。QBASICから来た私は、「VB」の「V」に興奮しました。ビジュアルデザイナーは、スライスされたパン以来、文字通り最高のものでした。 もちろん、これらすべてをプログラムで行うことはできますが、「V」の魔法は非常に魅力的で、ボタンをドラッグせざるを得ませんでした。私たちはその道を進むように勧められました。 しかし、それから数年前、私はC＃と.netフレームワークについて学び始め、自分が知っていると思っていたすべてのものが窓から出て行ったばかりの方法に魅了されました。VB6には、.netで完全に明らかにされた多くの魔法がありInitializeComponentsます。たとえば、コンストラクターとメソッドを見てみましょう。後者では、ツールボックスからドラッグしたすべてのコントロールインスタンス、登録したすべてのイベント、およびデザイナーで設定したプロパティが見つかります。 そして、それは結構です...私は推測します。ただ、私は何が起こっているのかを "所有"していないように感じます。このコードは、デザイナーを介してのみ変更でき、煩わしいことに煩わされます。「OK」と書かれたボタンをあるフォームから別のフォームにコピーするたびに（その兄弟の「キャンセル」とともに）、実際にコードを複製しているのは間違いです。教皇は言っています。 宗教と思想学派はさておき、すべての客観性において、代わりに基本フォームからフォームを派生させて、[OK]ボタン（およびそのすべての友達）を基本フォーム上に置くべきではありませんか？FormBaseから派生するのようなものDialogFormBase。すべてのクラスはすぐに作成されます...コードを入力してください。ボタンは、クラスがどのようにインスタンス化されるかに応じて作成されます（つまり、コンストラクタ列挙引数がどのボタンを作成するかを決定します）、コントロールは、分割パネルとフローレイアウトパネルの配置内にレイアウトされ、次のようにフォームに注入されますContentメインコンテンツパネルに収まります。これは、ASP.netがマスターページとコンテンツプレースホルダーで行うことではありませんか？新しい「マスターページ」が必要になったときにフォームを派生させますが、この新しい「マスターページ」は依然としてベースフォームクラスから派生しているため、アプリケーション全体でビジュアルが一貫しています。 私にとっては、WinFormsのデザイナでこれまでに行った他のどのコードよりもはるかに多くのコードの再利用であり、難しくもありませんでした。また、自分で制御できない200行のメソッドがコードに散らばっていません。私が好きな場所にコメントを付けてください。デザイナーによって上書きされることはありません。：私はそれだけでこのリンクを私にもたらしたものですパターンとアーキテクチャの問題、だと思う共通の機能を共有するWindowsフォームのベストデザイン私は除いて、上のスポットに気づいた、そこに答えは、私は正確に何を示唆しています実行しますが、デザイナーの考慮事項のため、フォームの継承はお勧めしません。それは私が得ない部分です。コード構造の考慮事項のため、特にフォームとコントロールの継承に関しては、デザイナーを壊す以外に避けるべき理由はないと思います。 私たちはすべて怠惰になることはできないので、どの部分が欠けていますか？

9 architecture  winforms  designer 

私はWindowsアプリケーションを開発していて、ラベル、ラジオボタン、ボタン、チェックボックス、グリッドの列ヘッダーのすべてのテキストを1か所に保存したいと考えています。クラスファイル、xmlファイル、データベーステーブル、リソースファイルを使用してみました。 クラスファイルがこれらすべてのテキストを保存するための最良の方法であることがわかりましたが、別の方法があることを知りたいですか？クラスファイルを使用している場合、テキストが変更された場合はプロジェクトを再コンパイルする必要があります。 リソースファイルは、大量のデータに対して適切に機能しますか？辞書や変数へのデータの保存はどうですか？

9 c#  resources  winforms 

Visual Studioを使用して作成した無料のC＃ソフトウェアをリリースしています。将来的には、これらのソフトウェアの一部が有料になる可能性があります。彼らのためにどんな種類のライセンスも購入する必要があるのか​​と思っていましたか？ ソフトウェアを販売しようとしているが、アプリケーションについてはどうですか？ ウイルス対策/ブラウザがアプリケーションを信頼できないものとしてフラグ付けしたくないのです。任意の提案をいただければ幸いです。

9 c#  commercial  winforms