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