Dates

Nowhere in a form should a Date be hand-entered by the User. As there are so many ways that a date could be entered by the user, Y2K vulnerabilities and issues with date masks, the use of a popup calendar is preferred.

This can be achieved by a read-only text box, which displays the date in the selected format. There is a small button to its right. The box and button appear like a combo box.

The button calls a small popup calendar. If the text box contains a valid date, then the calendar displays the month of that date. If the text box is empty, the calendar displays the current month. The calendar can be scrolled by month or year. If the User closes the calendar, no action is taken. If the User selects a day, the text box now contains that day.

There are many popup calendars available. Be sure to include them in wrapper functions, to simplify their use.

 Right click on this link for an Access 2000 demo of this : Harvey's Date Entry Demo

Form Closing

Calling forms should not close themselves after the called form opens. This is because MS Access loses stack space each time this happens, as no clear handshaking occurs. EG If Form1 is to call Form2, then Form1 opens Form2, then the OnOpen Event of Form2 should close Form 1.

Forms may not be closed whilst there is a current process active, nor may they be closed causing interruption to the validation process. This is very common, and very NAUGHTY. It is often done because the developer either doesn't care, or know how to resolve this.

In the Declarations section of the form put :

Private bln_OKToClose As Boolean

Initialise the variable in the Form OnOpen event :

bln_OKToClose = False

Stop the form from closing in the OnUnload event if this variable does not change state :

Cancel = Not bln_OKToClose
 

Clear this variable if the data validates OK in the BeforeUpdate event :

If <validation expressions> Then bln_OKToClose = True

Make a close button with :

If Me.Dirty Then  '-- This will force the BeforeUpdate event, if dirty
  DoCmd.SelectObject acForm, Me.Name, False
  If Me.Dirty Then DoCmd.RunCommand acCmdSaveRecord
End If

If bln_OKToClose = True Then DoCmd.Close acForm, Me.FormName

Generic Menu Bar

A MDI form may have a specific Horizontal Main Menu, else a generic one. Do NOT leave a form with the default Access menu bar. Your application should do everything.  If you do not need a menu specific to the current form, then use a generic one.

A specific Horizontal Main Menu may have special options, together with similar options on the Generic Horizontal Menu.

 The Generic Horizontal Menu for forms may have the following six main menu options :

 
File

View

Record

Filter

Filter is not always useful as the fields will be in your naming scheme, the user may not be proficient in query building, or the underlying data may not be representative of what is displayed.

Print

Close

This option Closes the current form and returns control to the Main Menu.

General

Forms should be fully validated.

No option should be offered at any moment that it is inapplicable.

Where appropriate, filtering should be applied to the record-source, rather than the form, returning less records and improving form performance.

Form Properties should be set to the minimum required.

Where an internal code module is not used Has Code Module should be set to No.

Tab Order should be set.

Command Buttons which bear legends should use Speed-Keys.

Cycle should be set to Current Record

Forms should use drop-down lists or list-boxes where applicable. In cases where the lists are large or require complex querying, causing delays, then these lists will be held in global static recordset in memory and processed by means of call-back procedures or, for later versions of Access, use the recordset directly. For .MDB's and .MDE's, when large lookup tables are commonly used as sources for combo-boxes and list-boxes, consider using static memory-resident datasets presented to the controls, or call-back procedures.