我们有一个应用程序,它必须灵活地向用户显示它的主表单 - 根据用户的不同,表单应该略有不同,可能在这里或那里有一个额外的按钮,或者其他一些细微差别。为了停止编写代码来显式删除或添加控件等,我转向视觉继承来解决这个问题——我认为这是一种整洁、干净和合乎逻辑的 OO 风格——结果表明,有一半的时间继承的表单很难无缘无故地在 VS 中渲染自己等等——我觉得开发人员和微软在某种程度上回避了视觉继承的做法——你能证实这一点,我在这里遗漏了什么吗?
问候。
我们有一个应用程序,它必须灵活地向用户显示它的主表单 - 根据用户的不同,表单应该略有不同,可能在这里或那里有一个额外的按钮,或者其他一些细微差别。为了停止编写代码来显式删除或添加控件等,我转向视觉继承来解决这个问题——我认为这是一种整洁、干净和合乎逻辑的 OO 风格——结果表明,有一半的时间继承的表单很难无缘无故地在 VS 中渲染自己等等——我觉得开发人员和微软在某种程度上回避了视觉继承的做法——你能证实这一点,我在这里遗漏了什么吗?
问候。
我认为他们或多或少地解决了 2005 年的桌面设计器问题。您是否尝试过通常的罪魁祸首?
我似乎认为,只要您完成了上述所有操作,它就可以工作……主要是。
我正在研究(不可否认即将过时的)MCAD,WinForms 元素的一部分是视觉继承。
我个人对此没有什么大问题,但是,需要考虑一些因素。
对我来说,主要问题始终是初始化.. 你需要记住,设计器不能/不以与运行时相同的方式实例化表单(同样,它不能用 web dev 做到这一点,这就是为什么需要小心带有自定义控件渲染)。
此外,一旦更改了表单,就需要对项目进行完整的重新构建,以便将对表单的更改传播到从它继承的子表单。
我个人没有看到任何证据表明它已被“回避”。AFAIK,在可能的情况下进行代码重用仍然是一种很好的做法。视觉继承提供了这一点。
我可以建议使用示例代码针对您遇到的实际问题创建一个新问题吗?然后我们可以查看它,看看我们是否可以让它工作并解释原因:)
我已经在 VS2005 中看到了一些问题。它们主要是由于设计器中表单对象的构造问题。尝试从表单构造函数等访问数据库的代码存在问题。
您可以通过启动 Visual Studio 的第二个实例并在调试器中加载第一个实例来调试此类问题。如果您在代码中设置断点,则可以首先调试设计器中发生的情况。
我记得的另一个问题是表单类中的泛型
public class MyForm<MyObject> : Form
这行不通
我经常在 Visual Studio 中偶然发现此类问题。在许多情况下,MSVS 表单设计器无法正确呈现表单。回到我使用 WinForms 的日子里,我不得不做各种奇怪的技巧来启用一些复杂的场景。但是我认为使用视觉继承是非常有益的,无论 MSVS 设计器错误如何,都不应该丢弃。
我想我已经找到了避免这个问题的方法。
不要在父表单中挂钩 Form_Load 事件,这会破坏设计器。
也不要在父窗体中将默认空构造函数从 Visual Studio 中取出。如果要进行依赖注入,请创建另一个构造函数。
像这样:
public ProductDetail()
{
InitializeComponent();
}
public ProductDetail(ISupplierController supplierController) : base()
{
InitializeComponent();
this.supplierController = supplierController;
}
然后,您仍然可以从继承的表单中执行此操作:
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 使用 3rd 方网格控件没有任何问题,但你必须小心,特别是必须避免从集合中删除项目。