在Visual Basic程序中使用许多不同的菜单/屏幕/表单的最佳做法是什么？是否只为我想要的每个菜单或屏幕制作一个新表格？还是有其他更好的选择吗？
我并不是想让这个过于复杂，我有一个小组项目可以继续工作，我们都有不同的技能水平。这说它已经让我的好奇心达到了顶峰，所以我认为在开始之前询问它并没有什么坏处。
答案 0 :(得分：1)
在我的情况下，当我处理多个表单时，我使用MDI Parent Form来避免Windows任务栏中的多个项目。
另一个不寻常的解决方案是将每个表单ShowInTaskbar属性设置为false。
答案 1 :(得分：1)
我可以看到这个问题因为过于开放而很快就会被关闭，所以在发生这种情况之前允许我加入我的关键抱怨......没有.TabControl页面的可见属性？说真的，微软??
这让我想到了关键点。如果表单在某种程度上相关但不一定相同，我更喜欢使用具有不同选项卡的单个表单，尽管控件中存在明显的缺点。 （你不必在远处寻找SO上的解决方法，但解决方法仍然是一种解决方法。）在运行时动态操作控件是这个硬币的另一面，尽管我更倾向于使用它......但那只是个人的事情。
例如，在最近的一个应用程序中，我列出了几种类型的对象。它们是相关的，但执行完全不同的功能，用户不一定需要同时查看多个列表。因此，我使用了一个表单，每个对象列表都有一个选项卡，以保持用户＆＃39;显示不那么杂乱。
同样在最近做一个GL应用程序时，我在一个表单的不同部分中有日志标题和日记行条目（它们转到后端数据库中的不同表）。另一方面，尽管创建过程共享了一些基础数据，但资产创建却与我创建了不同的形式完全不同。 （即日记行数据。）
我不相信＆＃34;最佳实践＆＃34;因为在一种情况下，良好的做法在另一种情况下可能是非常糟糕的。然而，＆＃34;经验法则＆＃34;我使用的是： - 将表格数量保持在最低限度，以保持低开销并减少维护但是 - 如果没有合乎逻辑的＆＃34; tie＆＃34;在两个函数之间，不要害怕创建一个新的形式，因为试图保持一个执行7种不同角色的形式是疯狂和挫折的保证路径，特别是如果你无意中破坏了某些东西。
是的，这两条规则有冲突，但在某种程度上我认为设计的这个方面类似于数据库规范化;在过度标准化（每个显示器的单独形式）和标准化不足（尝试将太多不相关的功能变成一种形式）之间存在一个最佳点。至少规则总是让我停下来思考＆＃34;我需要这个表格，还是与我已经做过的事情有关？＆＃34;
显然，第三个经验法则是......从用户的角度来看它总是看着它。他们是否会觉得你过多地反弹他们？所有表单是否都具有外观和感觉，更重要的是控制布局，以便他们始终知道在哪里可以找到某些内容？
所有这些因素都会因应用而异，并且从来没有一种适合所有恕我直言的尺寸。