看到界面设计的原则中，有一条是：灰色而不是隐藏，意思是说，当一个功能当前不可用时，不要将它从菜单中移走，而是让它变成不可用（灰色），因为菜单的忽隐忽现容易让用户摸不着头脑，不利于让用户建立精确的心里模型从而加快学习软件使用的速度偶深以为然！看看微软的Office，的确是这样。偶现在要做一个MDI界面程序，正为菜单的设计而苦恼：第一：偶不想用菜单合并，因为菜单合并实际上只会将子窗口的同类菜单覆盖而不是真正合并到主窗体的菜单中，例如：假设主窗口有一个“文件”菜单，文件菜单下有“新建”、“打开”两项；子窗口也有一个“文件”菜单，文件菜单下有一个“另存为”项，那么打开菜单合并功能后，在运行时打开子窗口后，主窗口的“文件”菜单中只有一个“另存为”项了不知道是不是偶不知道哪里还有什么设置的地方可以让菜单合并时是真正的合并而不是覆盖第二：如果第一点所述无法解决（即菜单合并只能覆盖而不能真正合并），那么，根据前面所述的界面设计原则，只有将所有的功能菜单都添加到主窗口的菜单中，子窗体不再使用菜单，并且根据子窗体的状况不同，动态地允许或禁用（灰色）主菜单中的相关菜单项了，但是这样又带来两个问题：
1.程序设计中还有一个重要的原则是：尽量做到窗体的功能都在本窗体自身的代码中完成，不要轻易调用别的窗体的过程和函数。相信大家也认同这一点，即尽量降低窗体（代码）之间的耦合度。如果要遵守这一原则，而又如前所述只能在主窗体中设置菜单（因为考虑到菜单合并的不理想问题而不再在子窗体中设置菜单），那么岂不是所有窗体和子窗体的功能（菜单）都只能在主窗体的代码中完成？！
2.即使这样，动态允许和禁用菜单项的依据是什么呢？实际程序的情况是多个子窗体，多个子窗体可能同时打开，多个子窗体可能对同一菜单项的允许和禁用（灰色）产生争议还有一种说法是干脆放弃使用MDI程序，连微软现在也只在MMC中使用，其他应用程序，比如Word、Excel，都不是MDI程序
偶迷茫中，也不知道是不是正确表达了偶的意思
1.程序设计中还有一个重要的原则是：尽量做到窗体的功能都在本窗体自身的代码中完成，不要轻易调用别的窗体的过程和函数。相信大家也认同这一点，即尽量降低窗体（代码）之间的耦合度。如果要遵守这一原则，而又如前所述只能在主窗体中设置菜单（因为考虑到菜单合并的不理想问题而不再在子窗体中设置菜单），那么岂不是所有窗体和子窗体的功能（菜单）都只能在主窗体的代码中完成？！
2.即使这样，动态允许和禁用菜单项的依据是什么呢？实际程序的情况是多个子窗体，多个子窗体可能同时打开，多个子窗体可能对同一菜单项的允许和禁用（灰色）产生争议还有一种说法是干脆放弃使用MDI程序，连微软现在也只在MMC中使用，其他应用程序，比如Word、Excel，都不是MDI程序
偶迷茫中，也不知道是不是正确表达了偶的意思
我也同意这个观点，以前弄MDI的时候，也郁闷着呢，所以现在干脆不用MDI，因为MDI的确也存在缺陷……
1.就是在每个MDIChild窗体中不用菜单而用ToolBar,而且MDIChild窗体不能最小化，只要它显示就是最大化的，这样菜单和工具栏合并的效果很不错。字窗体的功能代码完全用ToolBar实现。
2.用ActionMainMenuBar
3.用ExpressBars的dxBarManager
我想1是最容易的，不用第三方控件就可以搞定，2,3也不错而且省代码量。