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.

NOTE

---

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.

The DateTimePicker and MonthView controls

New additions to the latest version of Visual Basic are the DateTimePicker (DTPicker) and MonthView controls. Both of these can be found in the Microsoft Windows Common Controls_2 6.0 component. Either control can be used for date entry and display.

The DateTimePicker control, shown in Figure 8-6, works similarly to a drop-down combo box: users can enter information directly into the text field at the top, or if they prefer they can use the drop down to reveal a Picker from which they can select their date. The control can also be used for the display and input of time information by setting its Format property to dtpTime, in which case the dropdown combo box is replaced by a Spin control. You can also replace the combo box with the spinner for the date display by setting the DateTimePicker control's UpDown property to True. The chosen date or time is made available to you through the control's Value property as a Date data type.

NOTE

---

When using a custom format with the DatePicker control, be careful to specify the month part with an upper-case M. If you use a lower-case m, the control will display minute information where you expected the month to be. This can lead to some very obscure results, such as 00/28/1998 if you set the custom format to mm/dd/yyyy.

Figure 8-6 Three implementations of the Microsoft DateTimePicker control

The MonthView control, shown in Figure 8-7, is a much simpler proposition. This control gives you a view similar to the Picker of the DatePicker control. The user can select a date using the mouse or the cursor keys; there is no facility for typing dates in directly. Two nice features are the ability to display more than one month at a time, and the ability to select a range of dates.

Figure 8-7 Two implementations of the Microsoft MonthView control

More alternatives

Before you resort to purchasing a third-party control, there are a couple more options for you to consider. The first is a source-code control shipped with the Microsoft Visual Studio 98 Enterprise Edition (Disc 3), the Visual Studio 98 Professional Edition (Disc 2), and the Visual Basic 6 Enterprise and Professional Editions (Disc1), all at the location \Common\Tools\VB\Unsupprt\Calendar. You could use this control as the basis of your own "corporatedate" entry control with the advantage of having access to the source code so that you can be sure it is compliant. There is nothing to stop you from including the CSafeDate class and the subclassed date functions within this control to take advantage of the improved windowing we looked at earlier in this chapter.

The other alternative is shipped with Microsoft Office 97 Professional. This is the MSCal control, which gives you a view similar to the MonthView control.

NOTE

---

With all these controls, and any third-party ones you are interested in, you must perform a thorough acceptance test before clearing them for use. We're not going to recommend any particular control, purely because we feel that you have to perform these tests yourself.

The Year 2000 DateBox Control

With the added burden of Year 2000 data-entry validation, development teams might well resort to third-party controls for date display and entry. There are a number of alternative options available when it comes to date validation. However, these will undoubtedly mean having to write validation code that must be used in every part of the application that reads or displays a date. More coding effort will be required to ensure consistency than if a custom control were to be used.

If you opt for a third-party control, it is important to evaluate the control thoroughly. Do not assume that because the control is sold commercially it will be Year 2000 compliant. It might not be! Your organization might have a set of Year 2000 guidelines. If not, adopt some. The guidelines in this chapter are compliant with most industry standards including the British Standards Institute (BSI). Once you have some guidelines to follow you should test any prospective date control against those standards. I would strongly suggest rejection of controls that fail—do not rely on updates to fix problems because you might compromise the integrity of your data before an update is available.

Some developers will prefer to write a custom date control to meet specific needs. This can be a good solution if you have requirements that cannot be met by other commercial components, or if ownership of code is desired to enable future enhancements. The DateBox control described in Chapter 14 is an example of a compliant date control that provides a number of features:

• Date entry is made easy for users by allowing them to enter a date in any format, e.g. 5/2/1998 or May 2 1998.

• The control forces users to enter a 4-digit year regardless of the date format used—Long Date or Short Date.

• Incorrect dates are displayed in configurable highlighted colors so users are aware that the input contains an error.

• The control is configurable so that errors are not reported until the application attempts to use the date. This avoids users having to break their flow—they can fix errors when they want to.

• The control is not capable of returning an invalid date; instead, a trappable error is raised.

The DateBox control uses a Date type for the date property that prevents errors from being introduced if a date is coerced from a String type to a Date type. Obviously in many cases an application must accept a Null value or a blank date—if a field is not mandatory, for example. These instances are allowed for by an additional property, DateVariant, which is a Variant type and can be data-bound. The DateVariant property can be set to any value; however, when the property is read-only, valid dates, a Null, or Empty can be returned—any invalid value causes a validation error.

Programmers suffer a common frustration when a third-party control offers only a percentage of the desired functionality. Achieving that other x percent usually requires a work-around or more commonly, a kludge! The DateBox control has some additional useful features. It allows you to disable weekdays; for example, you can stipulate that Sunday is not a valid day. You can also set a CancelControl property. What's that, you ask? The DateBox has an ErrorKeepFocus property, which as the name suggests causes the control to regain focus if the user attempts to leave the control when it has an invalid date. Obviously, this would cause problems if the user wanted to hit the Cancel button! Therefore, setting CancelControl to your form's Cancel button allows DateBox to lose focus only to that control.

Chapter 14 provides a detailed overview of the DateBox design and covers some broader issues dealing with ActiveX controls in general.