Visual Basic

Being Seen with Your Dates in Public: User Interface Issues

As I've stated earlier in this chapter, the biggest source of noncompliant dates is on the other side of the keyboard. You are most definitely not going to find a Year-2000_compliant sticker on your average user. This leaves us with some work to do. How do we both display dates and allow users to enter dates in a way that does not compromise our hard-won compliance?

Displaying Date Information

Your best course of action here is to always use the default formats when displaying dates. Within your applications this means using the FormatDateTime function with either vbGeneralDate or vbLongDate. Because the Short Date format generally lacks four-digit year information, avoid using vbShortDate unless space is at a premium.

By using these formats you are following standard conventions for the display of date information within the Windows environment. Users expect to see dates displayed in this way, and they expect any changes they have made through the Control Panel to be reflected across all applications. This will also make your applications friendlier to foreign markets in which the date formats might be different.

Date Entry

What is the best way of allowing users to enter dates into your applications? Sorry, there are no easy answers here. Ideally, we would like to force them to enter all dates complete with century information. In practice this isn't always a vote-winner with user groups. It might only be two extra keystrokes per date, but if you are a data entry clerk keying a thousand records a day, each record containing three date fields, that's six thousand additional keystrokes.

Simple text fields

You can enter dates in a couple of ways. The first is to use a simple TextBox control, and either write code within its events to validate a date entered, or write a new control around it. This approach has the benefit of being totally within your control (no pun intended). You can apply any rules you want because you are writing the implementation. There are a number of things to remember when taking this route.
  • Never trap the input focus in the date TextBox control. If the date is invalid, don't force users to correct it before allowing them to move to another control- they might be trying to cancel an edit.
  • Never force users to enter the date in a noncompliant way. Don't laugh-I have seen applications where users could only enter the date as "ddMMyy"!
  • If you allow entry in a noncompliant format, always echo the date back to the input fields as soon as it has been expanded, showing the century you have applied. This allows users a chance to re-enter the date in full if they do not agree with your expansion algorithm.


For a closer look at implementing your own date entry control see Chapter 14 by Chris De Bellott and myself. We discuss the design and implementation of a simple date entry control of just this type.