我经常需要使用模态对话框来编辑属性或应用程序配置设置，但我对如何验证它们并不感到高兴，并将验证结果呈现给用户。
选择和工具通常是： -
设计UI以便无效选择 根本不可能 - 即使用 “掩盖编辑”，范围限制 旋转编辑，
尝试并捕获错误 发现 - 立即对话或 用户无效时的反馈 价值进入某处（虽然， 因为这可能是由于 不完全进入，这可以 视觉上分散注意力）
检测更改时的错误 控制重点
确定后验证整个对话框 按下，并显示消息 方框显示出错了。
No.4通常是最简单，最快速的代码，但我对此并不满意。
你找到了哪些好的技巧来处理这个问题？
虽然这个问题相当通用，但在Delphi for Win32中可以很容易地实现一个理想的答案......
答案 0 :(得分：4)
与所有事情一样，这取决于。 :)我试着从用户的角度来看一些这些。
数字1.我不喜欢个人的面具编辑，但旋转编辑，预先填充的组合框等范围限制等内容对于一般的健全性检查非常有意义，它使用户的生活更轻松。
我认为2号可能会让用户痛苦地使用对话框。他们可能不会按照您认为的顺序输入信息，或者可能会留下一个不完整的字段并在最后返回它。
对于验证，我使用3和4的组合。
根据字段（例如所需的值），我可能会在每次按键时验证它，如果它无效，则禁用“确定”按钮。您可以获得幻想并更改坏字段的颜色或使用其他类型的可见验证器控件。这对用户来说是显而易见的，并且不会中断他们的“流程”。
当用户点击OK时，动态检查的内容（例如，对服务器的调用）就不会那么容易了。
答案 1 :(得分：2)
只是一个观察，但我看到很多用户填充对话框（特别是复杂的），他们不使用TAB键。他们倾向于点击/编辑组合单选按钮，因为他们“思考”答案或从不同的文档中读取。这个订单与您认为的不一样！我们作为程序员有希望合乎逻辑（队长，Spock说），但用户很好......
一种很好（但需要付出努力）的方法是让每个编辑器在更改或退出时自行验证，如果它无效，它只会更改颜色。然后，在“确定按钮”代码中的例程是一个简单的事情，即迭代控制列表并将焦点设置为第一个将自身报告为“无效”的焦点，直到没有。
我为航空业工作，专注于信用卡的东西，我有TTicketNumberEdit，TCardNumberEdit，TExpiryDateEdit，TFormOfPaymentEdit等，效果很好，因为在其中一些验证并不简单。如上所述，您需要尽早付出努力，但它会在复杂的对话框中得到回报。
答案 2 :(得分：1)
我认为N°4是进行验证的最佳方式，除了是最简单的＆amp;最快的代码，你所有的验证逻辑都在同一个地方，所以如果你需要连接数据库，比较2+输入等......一切都只做一次，
虽然：
N°1：在某些情况下，这可能是一个噩梦。更新
N°2/3：您必须了解与验证，输入更改，焦点，...相关的所有UI事件。 - ＆gt;重编码＆amp;难以调试
答案 3 :(得分：1)
JVCL提供了用于验证输入的组件集（TJvValidators等）。它标记没有有效输入的字段，并在用户将鼠标移到该标记上时向用户显示提示。 （我想我读过dotNET中的类似功能，但我从未使用它。）
虽然我喜欢这个概念，并且实际上已经在许多对话框中使用了这些组件，但我不太喜欢这个实现：它对cpu的使用感到困难，而且JVCL附带的预定义验证器并不是真的有用。当然，有权访问jvcl svn存储库，我可以停止抱怨并开始改进组件......
答案 4 :(得分：1)
不要忘记看看Jim的伟大的代码会话：Stop Annoying Your Users!
他有关于输入验证的一节经文......
答案 5 :(得分：0)
IMO，选项＃1应该是理所当然的，而不是可选的，并且尽可能地简化界面，同时仍允许用户输入应用程序所需的详细信息。不过，我不喜欢使用蒙面编辑。例如，如果我希望用户输入一个数字，我将只使用一个文本框，然后在保存字段值时尝试解析该数字。
对于直接验证，我使用＃4，除非有特殊情况需要使用其他方法之一。我喜欢让我的用户修改他们的输入，如果他们改变了主意，那么他们就会犯错误并自行修复它，因为他们已经知道他们的输入有错误。尽管如此，我确实帮助他们（即，如果表单字段为空或无效且他们点击了OK，我会在显示错误消息后关注/选择有问题的字段。）
在Windows窗体应用程序中执行＃2很少能够自行完成，因此我将完全避免将其作为主要的验证方法。然而，它可以有效地与＃4结合，但我认为在大多数情况下，这将是过度的。