"视觉继承"的发展现状是什么
我们有一个应用程序，该应用程序必须灵活地根据用户显示其主要表单给用户，该表单应稍有不同，可能在此处或者此处有一个额外的按钮，或者其他一些细微差别。为了停止编写代码以显式删除或者添加控件等，我转向视觉继承以解决我认为是一种整洁，干净且符合逻辑的OO风格的问题，结果发现一半的继承形式很难呈现主题在VS中没有充分的理由等，我感觉到开发人员和Microsoft在某种程度上都回避了Visual Inheritance的实践，我们可以确认这一点吗，我在这里遗漏了什么吗？
问候。
解决方案
回答
我经常在Visual Studio中偶然发现这样的问题。在许多情况下，MSVS表单设计器无法正确呈现表单。在我使用WinForms的日子里，我不得不做各种怪异的技巧来启用一些复杂的方案。但是我认为使用视觉继承是非常有益的，并且无论MSVS设计器的错误如何，都不应将其丢弃。
回答
我正在研究(肯定会过时的)MCAD，WinForms元素的一部分是可视继承。
我个人对此没有重大问题，但是，有一些注意事项需要考虑。
对我而言，主要问题始终是初始化。.我们需要记住，设计人员无法/不以与运行时相同的方式实例化表单(类似地，它不能通过Web开发人员来实例化，这就是为什么需要谨慎使用自定义控件呈现)。
同样，一旦更改了表单，就需要对项目进行完整的重新构建，以便将对表单的更改传播到从其继承的子表单中。
我个人没有看到任何证据表明它已被"回避"。 AFAIK，它仍然是在可能的情况下重复使用代码的良好实践。视觉继承提供了这一点。
我可以建议使用示例代码针对我们遇到的实际问题创建一个新问题吗？然后，我们可以查看它是否可以运行并解释原因:)
回答
我认为他们在2005年或者多或者少地解决了桌面设计师的问题。
我们尝试过常见的罪魁祸首吗？
- 没有抽象控件类型
- 没有任何形式的构造函数参数
- 初始化移至Form_Load而不是Ctor
- 与放置在其中的usercontrol / form相同的项目中没有控件
- 关闭所有文档->清理->重建
- 重启VS
我似乎认为只要我们完成了以上所有操作，它就可以工作了。
回答
我已经在VS2005中看到了一些问题。它们主要是由于设计器中表单对象的构造问题。尝试从表单构造函数等访问数据库的代码存在问题。
我们可以通过启动Visual Studio的第二个实例并在调试器中加载第一个实例来调试此类问题。如果我们在代码中设置了断点，则可以首先调试设计器中发生的情况。
我还记得的另一个问题是表单类中的泛型
public class MyForm<MyObject> : Form
这行不通
回答
我想我已经找到一种避免这种问题的方法。
不要将Form_Load事件挂在父窗体中，这会破坏设计器。
另外，不要从父窗体的Visual Studio中删除Default空构造函数。如果要使用依赖注入，请创建另一个构造函数。
像这样：
public ProductDetail()
{
InitializeComponent();
}
public ProductDetail(ISupplierController supplierController) : base()
{
InitializeComponent();
this.supplierController = supplierController;
}
然后，我们仍然可以从继承的Form中执行此操作：
public NewProduct(ISupplierController supplierController)
: base(supplierController)
{
InitializeComponent();
}
到目前为止，这对我有用，而且我也遇到了一些奇怪的设计师问题。
干杯，丹尼尔
回答
阅读此：http://cs.rthand.com/blogs/blog_with_righthand/archive/2005/11/10/186.aspx
AFAIK仍然存在可视继承问题，并且对象依赖于设计元素的集合，通常是网格控件等。我相信MS仍然消除了更改f.ex的可能性。继承的窗体/用户控件等形式的GridView。但是其他控件(如TextBox，Form，UserControl，Panel等)应该可以正常工作。
到目前为止，我自己使用第三方网格控件对VI都没有问题，但是我们必须特别小心，必须避免从集合中删除项目。
