我从我现在工作的以前的开发人员那里继承了一个应用程序框架。该框架利用多个父/子关系。在许多情况下,父母/父母/孩子会发生。我问他为什么不使用 MDI,他说几年前,当他开始时,MDI 在前面提到的关系场景方面存在重大缺陷。特别是与多个父母。
我的实际问题是;MDI还有这些缺点吗?& 那些曾与 MDI 合作过的人,您遇到过哪些问题以及您是如何克服这些问题的?
谢谢你!
我真的认为这是您继承的应用程序的一个缺点,它需要多个父母(你好紧密耦合的应用程序!)。
我曾经开发过一个应用程序(敲木头,我很快就不必再去支持它了),它的耦合可能很像你现在的样子。如果原作者简单地使用委托而不是“this.Parent.Parent.Parent.functionX”,我们可能已经能够在修复该应用程序的缺点方面取得更大的进步(委托甚至可能不是要走的路......) .
至于 MDI,我个人更喜欢它,但我不能说你的原始开发人员发现的缺点,因为我试图围绕他/她需要的关系进行设计。
毫无疑问,所有 MDI 都是一种将应用程序的所有窗口包含在一个明确标识的屏幕区域中的一种方式。现在,如果您的应用程序是一个应用程序,它有多个文档并且人们使用它并希望在不使用时将其“收起来”,那么 MDI 可能适合您。如果不是,那么不,它不是。
托尼
MDI 接口的一个问题是您无论如何都不能在您的 MDI 容器中注册无限的窗口(请参阅此 Microsoft 知识库项目)。我想我把它贴出来是因为我看到很多 MDI 应用程序在大量使用时遇到了这个错误。
我通常喜欢 SDI 接口,并使其在多个“某物”实例上共享相同的控件和窗口,而不是为每个“某物”实例生成一个新窗口。
我不知道程序界面的细节,但我还没有找到无法重新设计为 SDI 界面和一些模式对话框(如果真的需要)的东西。
我当然有时会在 MDI 中看到一些故障,但老实说,如果您想要复杂的东西,我可能会建议您查看 WPF 而不是 winforms。
听起来我需要进一步研究 MDI。我对 WPF 的评论很好奇,因为这与我迄今为止所学的相反。
此外,有趣的是,框架开发人员将他的架构称为 HDI(主机文档接口)。
谢谢!
当你打开一个无模式的子屏幕,并且你的父屏幕被最大化时,你只能以最大化的尺寸打开子屏幕,你不能像正常尺寸的屏幕一样打开它。