How do I force a control to retain focus if a user enters incorrect data?

December 09, 2002
URL:http://www.drdobbs.com/data-validation-strategies/184416789

In my application, I need to validate data entered into controls in a dialog. I'd like to do this when the user leaves the control. If there is an error, I'd like to keep them in the control until the data is corrected. I've tried using SetFocus() to force the control to retain editing focus, but it doesn't seem to work very well. Any ideas?

Although it used to be very common in the preWindows days to validate user-entered data at the moment it was entered, for the most part this has disappeared from the majority of newer applications, particularly as more have moved to the Web. Typically, data is validated upon the submission, saving, or sending of changes. These changes are then verified as a group and appropriate error messages relayed to the user if the data is incorrect. However, if this is done poorly, it doesn’t provide the user with the most timely feedback (ever fill in those long forms on the Web only to be told you misentered something a few pages back?).

The difficulty with forcing the user to stay put until data is entered becomes apparent when you consider the following user states:

1. The user entered some incorrect data and wishes to correct it.
2. The user entered some incorrect data and wishes to abandon the editing session altogether.
3. The user entered some incorrect data and wishes to move to another application (or even another window in the same application) before fixing the problem.

A developer setting out to solve the problem of keeping the user in a control until data is validated might only consider the first of those states and develop an algorithm similar to the following:

• If a WM_KILLFOCUS event is received by the control (or an NM_KILLFOCUS event is received by the parent of the control), verify the data.
• If data is valid, do nothing.
• The user entered some incorrect data and wishes to move to another application (or even another window in the same application) before fixing the problem.

When appropriate code is written for the algorithm, it usually seems to solve the condition described by the first state. However, once the application is in use by testers or users, it quickly becomes apparent that the other two states are also common. The challenge then arises as to how to know when the user wishes to stay and fix the problem (state 1), cancel the changes (state 2), or fix it later (state 3). Trapping on WM_KILLFOCUS simply doesn't provide enough context to know what state the user is in.

I've found that the only reliable way to solve this data validation problem is to tackle it along the following lines:

• Allow as much flexibility in a data entry control as possible including formatting.
  • When data is entered, attempt to determine what the user intended on entering and make appropriate adjustments automatically. An example is allowing a user to enter dates using any reasonable format and interpreting the data using a variety of parsing rules.
  • Add support for intellisense-style autocomplete of partially entered data to reduce risk of incorrect input.
  • Use masks or other filtering while entering data to eliminate invalid characters. Examples include accepting only numbers in a zip code control, or numbers and dashes in a phone number control.
• Inform user of invalid input data but do not require immediate changes.
  • A message box, balloon popup, or other notification is sufficient to indicate a problem. This could be done at the point of entry or when a set of changes is submitted (i.e., hitting the OK button on a dialog).
  • Automatically disable controls that have a dependent relationship to the current controls data.
  • Provide as much feedback in the message as possible. Pay particular attention to how to fix the problem, not just what is wrong.

Another way to approach this problem is to consider that the user should be in control of when data is submitted for verification and the application should be in control of how it is verified. If the application attempts to dictate the when part of the arrangement, it can frustrate the user, particularly when they make an editing mistake that they wish to fix. Nothing is worse than getting hit with in-your-face error message boxes when trying to back up and fix a problem in a control.

Recently, I was using the navigation system in my car (pretty cool, by the way) and noticed how much care had been taken to ensure that I could not enter bad data. Particularly when entering a destination address, which is easily misspelled or miskeyed. As I enter the address, the nav system determines what streets begin with those letters and removes any other characters from the digital on-screen keyboard that would result in unknown or invalid street names. As I get closer to the actual address, my character choices become fewer. When I get to the actual street, the nav system will often guess the final characters and present the street to me for final approval. This is so much better than asking me to enter a street, misentering it, getting told that it is wrong, and then having to figure out what I mistyped. This kind of forgiving user input system is what every developer should strive to provide. It does take more effort, but in the end your users will thank you for it.

Mark M. Baker is the Chief of Research & Development at BNA Software located in Washington, D.C. Send your Windows development questions to [email protected]. To subscribe, visit http://www.windevnet.com/newsletters/.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.