具有许多控件 UI 模式的 Windows 窗体
我有一个包含近 60 个控件的表单，客户希望所有这些信息都可以填写在一个表单上，因为所有这些信息都与一个文档相关。有一些可用的模式可以做到这一点吗？我看到处理此类问题的一些方法：
- 将许多控件放在一个带有垂直/水平滚动的页面上（例如，我讨厌滚动，不认为该决定合适）。
- 为部分创建标签页。但这里有一个小问题：这些部分并不真正存在，因为所有信息都与一件事相关。虽然我仍然可以创建一些部分，但必须立即保存/验证所有选项卡页。
请针对此类问题提出一些常见做法。
I have a form with almost 60 controls on it and the client wants all that information to be fillable on one form, because all that is related to one document. Are there some usable patterns to do that? Some ways of dealing with such problem i see:
- put many controls on one page with vertical/horizontal scrolling(for example i hate scrolling, dont think that decision is suitable).
- create tab pages for sections. But here is a small problem: the sections are not really there, because all information is related to one thing..Tho still i can create some sections, but must save/validate all tab pages at once.
Please suggest some common practices for such problems.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，我的应用程序的表单远不止这些，所以我能感受到你的痛苦。
我会避免滚动条。当有滚动条时，用户很难确定他们已经看到了所有内容。
我推荐页面控件（即选项卡）。我确信，如果您足够努力，您会发现某种有意义的分组。
您有时看到的另一种类似于页面控件的方法是页面，但带有“下一步”/“后退”按钮。这样做的问题是它是不必要的线性。
就验证提供建议比较困难。如果验证仅取决于所讨论的单个值的值，则在输入时进行验证。考虑使用颜色突出显示而不是对话框。仅当用户尝试关闭对话框时才显示硬故障对话框。
验证其有效性取决于其他用户输入的值更加困难。我会将其推迟到对话框关闭时间。
Well, my app has forms with far more than that on and so I feel your pain.
I would avoid scroll bars. It's much harder for the user to be sure that they have seen everything when you have scroll bars.
I'd recommend page controls (i.e. tabs). I'm sure if you try hard enough you'll find some sort of grouping that makes sense.
The other approach you sometimes see used which is similar to a page control is pages but with Next/Back buttons. The problem with this is that it is needlessly linear.
It's harder to advise on validation. If the validation only depends on the value of the single value in question, then validate on entry. Consider using colour highlighting rather than dialog boxes. Only show hard fail dialogs when the user tries to dismiss the dialog.
Validation for values whose validity depend on other user input is harder. I'd postpone that to dialog dismiss time.