Export (0) Print
Expand All
Expand Minimize

Access Form Tips: Pitfalls to Avoid

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.
 

Luke Chung
FMS, President

September 2002

Applies to:

   Microsoft® Access (2.0, 95, 97, 2000, 2002)

Summary: This article offers tips to developers to help them avoid some of the pitfalls when creating Access forms. This article applies to Microsoft Access databases (.mdb) and Microsoft Access projects (.adp). This article assumes knowledge of creating Access forms.

Contents

Introduction
Pitfalls
Additional Resources
Conclusion

Introduction

Access forms are extremely powerful. However, the developer can easily make mistakes to cause a form to behave incorrectly or poorly. Here's a simple checklist of common problems with form designs. Developers should verify that these problems do not exist prior to finalizing their forms.

Pitfalls

Check these items on your forms before you distribute them:

  • Verify that the tables and queries used by the form are valid. This includes checking the form's record source and the row source of all combo boxes and list boxes.
  • Use a form caption. Without a caption, the name of the form appears, which may not be what you want your users to see.
  • Make sure that what the user sees is accurate and spelled correctly. In addition to the labels, the user also sees validation text and control tip text. A common mistake occurs when a control with these properties is copied, and only the label and control source are changed. In this case, other properties such as validation rule, input mask, default value, and format may also be wrong.
  • Make sure accelerator keys (hotkeys) are not duplicated. Accelerator keys allow users to press the ALT key and a letter to jump to a control. They are set by using the "&" character in captions followed by the letter. For instance, a Help button may have an "H" hotkey and appear as Help with its caption &Help. A common mistake is to assign the same key to multiple controls on the form. Test your form by using each hotkey twice, and verify that it doesn't go to more than one control.
  • Make sure all command buttons have an OnClick event. If it doesn't have an OnClick event, the button should be removed, made invisible, or fixed. Sometimes the OnClick event is accidentally assigned to the wrong event, such as the OnDblClick event. Alternatively, an OnClick event is not necessary if it has a hyperlink.
  • Make sure the tab order of the controls is correct. By default, the tab order should go from left to right, top to bottom. This is what users expect. If your form does not behave this way, it exhibits unexpected (unintuitive) behavior, which can be frustrating for your users. The default tab order can be easily set under the View, Tab Order menu. For situations in which you want the tab order to behave differently (for instance, you may want it to go down columns for an option group), you can change this, but at least you're making a deliberate decision to deviate from the default order.
  • For the BackColor property of form sections and controls, use the system gray color (-2147483633) rather than the default gray (12632256). In recent versions of Microsoft Windows® (Windows Me, Windows 2000, and Windows XP), there's a slight change in the way gray is displayed, and the older gray appears darker than it should. Mixing these two values for older Windows versions is not a problem, but you can see a difference on new versions.
  • Views allowedAllowed should be explicitly assigned to only display the way you want your users to see the form. Options include viewing the form in form view, datasheet view, and in Access 2002, PivotChart and PivotTable Report views. Without the undesirable optionsturned off, a user can change the view of the form by right clicking on the form and switching with the shortcut menu.
  • By default, the Shortcut Menu property is set to Yes, and no shortcut menu is specified. This means the default Access menu appears. If this is not desired, set this property to No.
  • If you are using a help file, make sure the help file name and help context ID are correct.
  • Make sure every event that has [Event Procedure] assigned actually has an event procedure defined. A common mistake is to assign the event without actually clicking through to write the code for it. This can also happen if you rename a control and forget to rename the event procedures that are tied to the old name.
  • Make sure the AutoCenter property is set to Yes. AutoCenter ensures that when your form is opened, it opens in the center of the screen regardless of where you placed it when you saved it on your computer, and regardless of the user's screen resolution.
  • Make sure the AutoResize property is set to Yes. AutoResize automatically adjusts the display of your form to the size you designed it. If this property is set to No, the form appears in the way you last saved it, which can easily be too big or small.
  • Combo boxes should have their LimitToList property set to Yes so users can only enter values in the list. If this is set to No, a NotInList event should handle new values.
  • Combo boxes should have their AutoExpand property set to Yes to simplify data entry by auto-filling what users type.
  • The AllowDesignChanges property should not be set to All Views, but rather to Design View Only. When set to All Views, users can change the design even though they are not in design view. This is rarely desired behavior. In fact, if the form property sheet is left open when the form was last designed, the property sheet also appears, which is very confusing to end-users. By default in Access 2000, this setting is set to All Views. In Access 2002, the default was more appropriately set to Design View Only.

Additional Resources

Making sure that forms are properly designed takes time and effort to verify all the things that could go wrong. This is especially difficult if you are taking over someone else's work and/or if there are a large number of forms. Fortunately, there are some tools that can address some of the pitfalls listed here by examining all your forms and highlighting the problems.

The first is http://www.fmsinc.com/Products/analyzer/index.html from FMS, Inc. Total Access Analyzer is a comprehensive Access database analysis tool that covers much more than forms. With the exception of verifying the accuracy of what users see, the form analysis detects all the other pitfalls listed here. Total Access Analyzer is available for Access versions 2.0, 97, 2000, and 2002.

The second tool is http://www.fmsinc.com/Products/speller/index.html, also from FMS, Inc. Total Access Speller is a spell-checker that checks what the user sees on your forms, reports, and other objects. You can easily verify that all the captions, validation text, and control tips are properly spelled. Total Access Speller is available for Access versions 2.0, 97, 2000, and 2002.

Conclusion

Developing an application takes a lot of effort. Don't let simple mistakes ruin your application and embarrass you in front of your boss or clients. Even a simple typo can ruin the trust a user has for your application, work, and attention to detail. It usually only takes a few minutes per form to ensure that those who use it don't see obvious problems. This is a wise investment of your time for your career and reputation. Use this checklist as the basis of your quality assurance process for your forms. If you find other problems, add them to the list so you can avoid them in the future. Making mistakes is okay. Making the same mistake more than once means you're not learning. Good luck.

Luke Chung is President and Founder of FMS Inc., a leading provider of third-party products for Microsoft Access users and developers.

Show:
© 2014 Microsoft