0

在 Visual Basic 程序中拥有许多不同的菜单/屏幕/表单的最佳实践是什么？是否只是为我想要的每个菜单或屏幕制作一个新表格？还是有其他更好的选择？

我不想让这件事变得过于复杂，我有一个小组项目要做，我们都有不同的技能水平。那就是说它已经达到了我的好奇心，所以我认为在我开始之前问它不会有什么坏处。

4

2 回答 2

1

就我而言，当我处理多个表单时，我MDI Parent Form会避免在 Windows 任务栏中出现多个项目。

另一个不寻常的解决方案是将每个表单ShowInTaskbar属性设置为 false。

于 2012-10-23T00:43:37.890 回答
1

我可以看到这个问题很快就结束了，因为它太开放了，所以让我在此之前得到我的关键抱怨...... TabControl 页面没有 .Visible 属性？说真的，微软？？

这让我想到了关键点。如果表单在某种程度上相关但不一定相同，我更喜欢使用具有不同选项卡的单个表单，尽管控件中有明显的缺点。（在 SO 上您不必费力寻找解决方法，但解决方法仍然是一种解决方法。）在运行时动态操作控件是这枚硬币的另一面，尽管我倾向于很少使用它。 .但这只是个人的事情。

例如，在最近的一个应用程序中，我有几种类型的对象的列表。它们是相关的，但执行完全不同的功能，用户实际上不需要同时查看多个列表。因此，我为每个对象列表使用了一个带有选项卡的表单，以使用户的显示不那么混乱。

类似地，最近在做一个 GL 应用程序时，我在一个表单的不同部分中有日记帐标题和日记帐行条目（它们转到后端数据库中的不同表）。另一方面，资产创建完全不同，我创建了一个不同的表单，尽管创建过程共享一些基础数据。（即日记帐行数据。）

我不相信“最佳实践”的概念，因为在一种情况下是好的做法在另一种情况下可能是非常糟糕的做法。然而，我使用的“经验法则”是： - 将表单数量保持在最低限度，以保持低开销并减少维护但是 - 如果两个功能之间没有逻辑上的“联系”，不要害怕做一个新的形式，因为试图维持一种执行 7 种不同角色的形式肯定会导致疯狂和沮丧，特别是如果您无意中破坏了某些东西。

是的，这两条规则有冲突，但在某种程度上，我认为这方面的设计类似于数据库规范化；在过度规范化（每个显示器都有一个单独的形式）和规范化不足（试图将太多不相关的功能塞进一个形式）之间有一个最佳点。至少规则总是让我停下来思考“我需要这个表格，还是它与我已经做过的事情有关？”

显然，第三条经验法则是……始终从用户的角度来看待它。他们会觉得你在他们身边弹跳太多了吗？所有表单是否共享外观和感觉，更重要的是，控制布局，以便他们始终知道在哪里可以找到某些东西？

所有这些东西都会因应用程序而异，而且从来没有一种尺寸适合所有恕我直言。

于 2012-10-23T01:40:57.920 回答