mfc CEdit什么时候应该进行验证？

Question

因此，基于标题，我应该何时在CEdit（文本框）上进行验证？

背景：我被转移到我们公司的一个新的开发小组，他们的做法是按Enter键，那就是他们在CEdit（mfc对话框）上进行验证的时候。而我，来自.net，特别是来自WinForms，其中有Validated和Validating事件，每个开发人员都会看到并意识到这是您应该进行验证的正确事件。

我的问题是：

我应该遵循他们的做法（按回车键）？ 或者我的想法是使用EN_KILLFOCUS（与上述事件关系/相关）？或两者都不正确，是否有更适合验证的事件？

我需要你的建议，因为如果我的共同开发人员被问到，那么他们都会立即说我应该按Enter键来处理验证。谢谢！

Answer 1

即使在我的公司，我们也有两个派对。

第一方严格说信息仅在按下Enter时验证，因此在所有信息可用时。如果你有一堆相互影响的信息很容易，这种方法很有用。 MFC DoDataExchange方法是他们的最爱。

第二方说：必须尽早验证信息。我认为当每个值几乎独立时，这种方法是可行的。在这种情况下，您检查EN_CHANGE或EN_KILLFOCUS上的所有数据，并禁用确定按钮，直到所有数据都有效。

第二种方法的不利之处在于，您必须在输入数据时向用户提供更多信息，以指导他更正数据。第一种方法可以在一条错误消息中解释该问题。

我在我的程序中使用这两种方法。在大多数情况下，我们使用第一种方法，因为我们发现，具有详细信息的全面错误消息更易于维护和用户理解，因为当他们看到对话框时无法获得启用的OK按钮。 ..

BTW：我讨厌可以输入负数的对话框，其中只允许正数。始终使用您可以获得的正确和最佳输入字段，以获得最佳指导。因此按下输入后MFC方法说“超出范围”不是一个好的解决方案。如果您有最小值和最大值，您甚至可以在用户输入后直接更正该值。

但是这个答案和问题往往是基于意见的。

Answer 2

无论您决定做什么，都应尽量减少对用户工作流程的干扰。而且，与此同时，您需要与用户对验证行为的期望保持一致。不要让您的偏见影响对话行为，导致用户混淆，或者使用对话框的额外时间。要记住的最重要的事情是与你采取的任何方法保持一致。

Answer 3

1）MFC为许多数据类型提供验证工具。它取决于您要在该控件中输入的数据类型。这有可能使用这个设施吗？

在我看来，EN_KILLFOCUS是一个更好的选择，因为如何验证用户是否没有按Enter键并按Tab键移动到下一个控件？您仍然可以与同行讨论这个问题并得出结论哪个是处理验证的更好地方。