Questions tagged «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闻名的Anders Hejlsberg是C＃的架构师。我对Delphi的VCL定制组件非常着迷，尤其是那些涉及制作多步向导和充当子组件容器的组件的组件。 在这种背景下，我希望从Delphi转到C＃的那些人可以帮助我完成WinForms vs. WPF决策，以编写初始应用程序。请注意，当我进行编码时，我非常急躁，诸如成熟的自动完成功能和适当的调试器支持之类的东西可能对我来说成败一个项目，包括能够找到有关API功能和调用的随时可用信息，甚至更多的错误解决方法。 。 2009年初日期范围内的SO线程和注释使我非常担心WPF，因为它可能会破坏我的C＃UI开发代码。另一方面，花费大量时间来学习即使没有被放弃也即将被替换的API技术（WinForms），同样令人不安，我确实在WPF诱人中发现了GPU支持。 因此，我的矛盾情绪。由于我还没有学过任何一种技术，所以我有一个难得的机会重新开始，而且不必面对巨大的“无学习”曲线，当WinForms程序员转向WPF时，我已经看到人们在各个线程中提到了这一点。另一方面，如果对像我这样的耐心的RAD开发人员来说，使用WPF太令人沮丧或产生其他严重的负面影响，那么我将坚持使用WinForms，直到WPF达到相同的支持水平和易用性。为了给您一个具体的例子说明我作为程序员的心理，我使用了VB，随后又使用了Delphi，以完全避免使用MFC进行编码的真正痛苦，MFC是许多开发人员在开发早期Windows应用程序时都会遇到的Windows UI库。我从未后悔避免使用MFC。 知道Anders Hejlsberg是否参与过WPF和/或WinForms的体系结构，以及这两个代码库中体现的创意视野和易用性方面是否存在差异，也令人感到欣慰。最后，再次让Delphi程序员知道使用WPF而不是WinForms时需要多少“ IDE schock”，尤其是在调试器支持方面。2011年更新的任何就业市场评论也将不胜感激。

38 c#  wpf  winforms  delphi  microsoft 

不久前，我开始创建一个winform应用程序，当时它很小，因此我没有考虑如何构造项目。 从那时起，我根据需要添加了其他功能，并且项目文件夹越来越大，现在我认为是时候以某种方式构建项目了，但是我不确定什么是正确的方式，因此我没有什么疑问。 如何正确重组项目文件夹？ 目前，我正在考虑这样的事情： 创建表单文件夹 创建实用程序类的文件夹 为仅包含数据的类创建文件夹 添加类时的命名约定是什么？ 我是否还应该重命名类，以便仅通过查看其名称即可识别其功能？例如，重命名所有表单类，以便其名称以Form结尾。还是如果为它们创建了特殊文件夹，这是否没有必要？ 怎么办，以便不是主窗体的所有代码都以Form1.cs结尾 我遇到的另一个问题是，随着我添加的每个功能的主要形式越来越庞大，代码文件（Form1.cs）变得越来越大。例如，我有一个TabControl，每个选项卡都有一堆控件，所有代码最终都保存在Form1.cs中。如何避免这种情况？ 另外，您知道处理这些问题的文章或书籍吗？

26 .net  visual-studio  winforms  project-structure 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 我是一位经验丰富的Windows Forms开发人员，但是现在该搬到WPF了，因为一个新的WPF项目即将来临，而且我只有很短的准备时间来准备学习WPF。 有经验的Winforms开发人员的最佳方法是什么？ 您能给我一些在短时间内学习WPF的提示和建议吗？ 是否有简单的WPF示例解决方案和简短的（视频）教程？您推荐哪些书？www.windowsclient.net是一个好的起点吗？微软官方网站有替代品吗？

26 c#  .net  windows  wpf  winforms 

我正在Windows窗体上计算项目编号的UPC。 我成功创建了一个可一次处理一个物料编号/ 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窗体。如果我所有的表单都具有公共控件，插图和功能，那么我将创建一个实现公共控件和功能的基本表单，然后允许其他控件从该基本表单继承。但是，我在设计时遇到了一些问题。 控件一次只能放在一个容器中，因此您拥有的任何静态控件都将很棘手。例如：假设您有一个称为BaseForm的基本表单，其中包含一个TreeView，并对其进行了保护和静态处理，以便此类的所有其他（派生）实例都可以修改和显示相同的TreeView。这对于从BaseForm继承的多个类不起作用，因为TreeView一次只能位于一个容器中。它可能在初始化的最后一个表单上。尽管每个实例都可以编辑该控件，但在给定时间只能显示一个。当然，有一些变通方法，但是它们都很丑陋。（这对我来说似乎是一个非常糟糕的设计。为什么多个容器不能存储指向同一对象的指针？无论如何，它就是它。） 表单之间的状态，即按钮状态，标签文本等，我必须使用全局变量并在Load上重置状态。 Visual Studio的设计师并不能很好地支持此功能。 是否有更好但仍易于维护的设计可供使用？还是形式继承仍然是最好的方法？ 更新 从查看MVC到MVP，从观察者模式到事件模式。这是我目前的想法，请批评： 我的BaseForm类将仅包含控件以及与这些控件相关的事件。需要任何逻辑来处理它们的所有事件都将立即传递给BaseFormPresenter类。此类将处理来自UI的数据，执行任何逻辑操作，然后更新BaseFormModel。该模型会将事件（状态更改时将触发）的事件公开给Presenter类，该类将订阅（或观察）该事件。演示者收到事件通知后，它将执行任何逻辑，然后演示者将相应地修改视图。 内存中每个Model类只有一个，但是可能存在许多BaseForm实例，因此有BaseFormPresenter。这将解决我将BaseForm的每个实例同步到相同数据模型的问题。 问题： 哪一层应该存储最后按下的按钮之类的内容，以便我可以在表单之间为用户（例如CSS菜单中）突出显示它？ 请批评这个设计。谢谢你的帮助！

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

我知道有像MVC这样的模式可以将视图与逻辑分开，但是，我不知道它们在Winform应用程序中有多常见。 对于C＃Winform应用程序，我可以从开始Form并逐步向其中添加UI组件，然后针对组件的事件（click，textchanged...），我调用函数，或直接在其中编写逻辑！ 我知道这是一个坏习惯，但是我不知道在Visual Studio中启动此类项目的最佳方法是什么（模板，框架，起点），MVC是唯一的解决方案吗？我应该为任何项目这样做吗？ 我希望获得一些入门指南或轻量级框架。

18 c#  mvc  winforms 

我过去曾经使用过MVP和MVC，我更喜欢MVP，因为我认为它可以更好地控制执行流程。 我已经创建了我的基础结构（数据存储/存储库类），并且在对示例数据进行硬编码时可以毫无问题地使用它们，因此现在我转向GUI并准备我的MVP。 A节 我已经看到MVP使用视图作为入口点，也就是说，在视图构造方法中，它创建了演示者，该演示者又创建了模型，并根据需要连接事件。 我还以演示者为切入点，在其中创建了视图，模型和演示者，然后在其构造函数中为该演示者提供了视图和模型对象以关联事件。 与2中一样，但是模型没有传递给演示者。相反，该模型是一个静态类，在其中调用方法并直接返回响应。 B区 在使视图和模型保持同步方面，我已经看到了。 每当视图中的值发生更改时，即TextChanged.Net / C＃中的事件。这会触发一个DataChangedEvent传递到模型中的，以使其始终保持同步。在模型发生变化的地方（即它侦听的后台事件），然后通过引发的相同想法来更新视图DataChangedEvent。当用户想要提交更改SaveEvent时，它将触发，并进入模型进行保存。在这种情况下，模型将模仿视图的数据并处理动作。 与＃b1相似，但是视图并非始终与模型同步。相反，当用户想要提交更改时，将SaveEvent被解雇，演示者获取最新的详细信息并将其传递到模型中。在这种情况下，除非需要对视图数据进行操作，否则模型将不知道视图数据，在这种情况下，将传递所有必需的详细信息。 C区 在视图中显示业务对象，即不是原始数据的对象（MyClass）（int，double） 该视图具有将显示为域/业务对象的所有数据的属性字段。例如，view.Animals公开一个IEnumerable<IAnimal>属性，即使视图将它们处理到TreeView中的Nodes中。然后对于选定的动物，它将SelectedAnimal作为IAnimal属性公开。 该视图不了解域对象，它仅公开图元/框架（.Net / Java）包含的对象类型的属性。在这种情况下，演示者将把适配器对象传递给域对象，然后适配器将给定的业务对象转换为视图上可见的控件。在这种情况下，适配器必须有权访问视图上的实际控件，而不仅仅是任何视图，因此会变得更加紧密。 D区 用于创建单个控件的多个视图。即，您有一个具有简单模型的复杂视图，例如保存不同类型的对象。您可以在侧面有一个菜单系统，每单击一个项目就会显示相应的控件。 您创建一个巨大的视图，其中包含通过视图界面公开的所有单个控件。 您有几种看法。您有一个菜单视图和一个空白面板。该视图创建所需的其他视图，但不显示它们（visible = false），该视图还为其包含的每个视图（即子视图）实现接口，因此可以向一个演示者公开。空白面板中将填充其他视图（Controls.Add(myview)）和（(myview.visible = true）。这些“子”视图中引发的事件由父视图处理，父视图又将事件传递给演示者，反之亦然，以将事件提供给子元素。 每个视图（无论是主要父视图还是较小的子视图）均连接到自己的演示者和模型中。您可以从文化上将视图控件放到现有的表单中，它将具备功能，只需将其连接到幕后的演示者中即可。 E节 如果所有内容都具有接口，那么现在基于以上示例中MVP的完成方式，由于它们可能不是交叉兼容的，因此将影响此答案。 一切都有界面，视图，演示者和模型。然后，显然每个都有具体的实现。即使您只有一个具体的视图，模型和演示者。 视图和模型具有接口。这允许视图和模型不同。演示者创建/获得视图和模型对象，并且仅用于在它们之间传递消息。 仅视图具有界面。该模型具有静态方法，不会创建，因此不需要接口。如果需要其他模型，则演示者将调用一组不同的静态类方法。由于模型是静态的，因此与演示者没有链接。 个人想法 从我介绍的所有不同变体中（大多数我可能已经以某种形式使用过），我确信还有更多。我更喜欢A3，因为它可以使业务逻辑在MVP之外可重用，而B2则可以减少数据重复和触发事件。C1用于不添加其他类，请确保将少量非单元可测试的逻辑放入视图中（如何可视化域对象），但是可以对其进行代码审查，也可以在应用程序中简单地对其进行查看。如果逻辑很复杂，我会同意一个适配器类，但并非在所有情况下都同意。对于D部分，我觉得D1创建的视图对于菜单示例来说至少太大了。我以前用过D2和D3。D2的问题是，您最终不得不编写大量代码才能将事件往返于演示者与演示者之间路由到正确的子视图，并且其拖放操作不兼容，每个新控件都需要更多接线才能支持单个演示者。D3是我的首选，但是即使视图恰好非常简单或不需要重用，D3仍会作为演示者和模型添加更多类来处理该视图。我认为根据情况，D2和D3的混合效果最好。对于E部分，我认为具有接口的所有内容都可能过头了，因为我已经对域/业务对象进行了此操作，因此这样做通常不会在“设计”中看到任何优势，但它确实有助于在测试中模拟对象。我个人认为E2是经典的解决方案，尽管我以前在2个项目中使用过E3。我认为根据情况，D2和D3的混合效果最好。对于E部分，我认为具有接口的所有内容都可能会过时了，我已经对域/业务对象进行了此操作，并且这样做通常不会在“设计”中看到任何优势，但是它确实有助于在测试中模拟对象。我个人认为E2是经典的解决方案，尽管我以前在2个项目中使用过E3。我认为根据情况，D2和D3的混合效果最好。对于E部分，我认为具有接口的所有内容都可能会过时了，我已经对域/业务对象进行了此操作，并且这样做通常不会在“设计”中看到任何优势，但是它确实有助于在测试中模拟对象。我个人认为E2是经典的解决方案，尽管我以前在2个项目中使用过E3。 题 我是否正确实施MVP？有正确的方法吗？ 我已经读过Martin Fowler的著作，其中有很多变化，而且我还记得当我刚开始做MVC时，我理解了这个概念，但是最初无法确定切入点在哪里，一切都有自己的功能，但是控制和创建原始作品的是什么MVC对象集。

14 c#  design  design-patterns  winforms 

我是一名C ++开发人员，此后一直使用MVC模式来设计GUI。 最近，我想重新使用C＃，并设置了Windows Forms应用程序，但现在我对如何将其推送到MVC兼容结构有些迷惑。 我当前要执行的操作是“声明”为WinForms提供的类作为视图，并在后台为Model和Controller添加类。但是，我不确定如何与事件交互，例如单击按钮。通常，我会将这些事件重定向到控制器，并在完成后对View执行操作。 但是，这对于这个星座来说是非常不满意的。例如，如果我想实现“退出”按钮，则必须将事件从View重定向到Controller，并在View中实现一个额外的公共方法，然后可以从Controller调用它，而我可以在第一个实例中简单地从View调用Close（）。 您对我有什么建议吗？我对C＃中的Windows窗体的理解还不够好，无法尝试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方法为例。在后者中，您将找到从工具箱中拖动的所有控件实例，已注册的所有事件以及在设计器中设置的属性。 很好...我想。只是，我感觉我不“拥有”正在发生的事情，我只能通过设计者修改的这段代码使我烦恼不已。每次将一个表示“确定”的按钮从一种形式复制到另一种形式（有时连同其兄弟“取消”）时，您实际上是在复制代码，这是一种罪过吗？教皇说，干，别重复。 除了客观存在的宗教和思想流派之外，我们是否不应该从基本表单中获取表单，并让“确定”按钮（及其所有朋友）都在基本表单上生活？像a这样的东西FormBase衍生出a DialogFormBase; 立即创建所有类...通过键入代码。根据实例的类的创建方式创建按钮（即，构造函数的enum参数确定要创建的按钮），将控件布置在拆分面板和流布局面板的内部，并按如下方式插入表单Content适用于主要内容面板。这不是ASP.net对母版页和内容占位符的作用吗？当我需要一个新的“母版页”时，我会派生一个表单，但是这个新的“母版页”仍然派生自基本表单类，因此整个应用程序的视觉效果是一致的。 对我来说，这是很多更多的代码重用比什么都重要，我曾经在的WinForms设计师做的，它甚至不是辛苦，代码不与200线方法混乱，我无法控制，我可以将评论放在我喜欢的位置，它们不会被设计师覆盖。我想这只是模式和体系结构的问题，这就是带我进入此链接的地方：能够共享通用功能的Windows窗体的最佳设计，我在那里发现，除了那里的答案外，我确切地表明了我的意思。这样做，但它建议对形式的继承，因为设计师的考虑。那是我不了解的部分。出于代码结构方面的考虑，尤其是在形式和控件继承方面，我认为没有理由要避免，除非这样做会破坏设计人员。 我们不能都只是懒惰，所以我缺少哪一部分？

9 architecture  winforms  designer