Logo

My Access Tips for Custom Microsoft Access

Application Development

by Matthew V Carmichael


Need Help?

My Tips


Links

Resources

The Basics - give your custom MS Access application a professional look.

A key aspect of an application success is its acceptance by the end users.  In the end, if users are not satisfied with the application, it will be short lived.  As developers we have many responsibilities and practices to follow as we create our applications.  Writing efficient code, security, business rules, ensuring data integrity, maintaining a normalized structure, documentation, and the list goes on.  The end user will never notice how many lines of code were written or how much time and effort it took to create a data entry form.  Regardless of how much work was put into an application, the first thing the user will notice is the application's limitations and flaws. 

For that reason it is very import to “win over” the end user.  We want the end-user to embrace the applications we have written.  If the application accomplishes what is was set out to do and is widely accepted by the end users, then we have success.

I have outlined some tips that I like to refer to as “finishing touches”. These tips will enhance the user interface and overall presentation of the application.

Create a splash screen

The splash screen serves several purposes.  It provides the user with information about the application and allows the user to visually see the application is opening.  Since the Main Menu may take several seconds to load – the Splash screen .

The splash screen should contain some basic information.

  • The name of the application
  • The Author
  • Version Number
  • Copy write notice, if necessary
  • Support Contact Information – email, phone, web site
Create a custom Toolbar for forms and reports

I believe each application should have at least two custom toolbars (One for forms and one for reports).   This will allow the developer to customize what features they want and don’t user to utilize.  You can also import you custom toolbar to your other Access applications (more info).

I have seen many custom Access applications where the developer hide and unhide toolbars at startup and shutdown.  I am not very fond of this method.  I think it is too much work and the toolbar/object association never seems to be correct in my other Access applications.  I remember at one point I began supporting an application (someone else had created) which used this method.  Every time I opened the application, my Compact and Repair command from the Tools > Database Utilities menu would be disable in Access, regardless of what application I was using (very annoying). 

Here are the basic toolbars I use.

Forms:

Form Toolbar

  • Save Record
  • Spell Checker
  • Cut
  • Copy
  • Paste
  • Undo
  • Sort Aces ending
  • Sort Descending
  • Filer by Selection
  • Filter by Form
  • Apply Filter
  • Find
  • New Record
  • Delete Record
  • Help
  • About

Reports:

Report Toolbar

  • Print
  • Print Preview
  • Zoom
  • Close
  • Office Links
  • Send
  • Help
  • About

To Implement

  • Create a Custom Toolbar
  • Set the Toolbar Property of the Form / Report to the custom toolbar
  • Modify the Tools > Start Up options
Create a custom Menu bar / Shortcut menu.

For the larger applications that have extensive custom features and functionality, I like to create my own menu bar and shortcut menu bar. This really gives the application a unique identity and makes it easy for users to navigate though the application. Try to logically organize the information and make commonly used commands accessible to the end user.

Menu bar Example Shortcut Menu Example
menubar shortcut menu
Create a help screen.

For many users, it may be the first time they have ever used Access or any database system. Proving a quick reference that explains some of the basic functions of the application. I once had a user key in fifty entries, never moving to a new record. When they were finished, only one entry was in the database (example).

Check for consistency in spacing & naming of form/report controls.

When the State field of a table is set to to a text data type with a field size of two, why does the data entry from look like it can accept 50 characters? Why does one form label the Address fields as “Address 1 and Address 2” while another form has them labeled as “Street and Address Line 2”? Why does one report sort Last Name, First Name and another First Name, Last Name? These kinds of inconstancies can frustrate and confuse the end user. It is a good idea to have someone who knows absolutely nothing about the application (maybe a friend or relative) test it. It is amazing what a fresh set of eyes will pick up.

Use Control Tips

Control tips are a great way to provide users with additional information about a field, command button, or a form control. Consider changing the color of the text or background to identify controls that contains tips. I place an orange circle to identify a control tip. The user can hover over the circle to read it. This is a great way to provide instructions or explain the logic of a specific function within the application.

controltips

Consider using hyperlinked labels in place of command buttons.

I use hyperlinked labels to open other forms though out my application.  For instance, I will hyperlink the customer label of an order entry from.  If the user clicks the label, the customer entry form is opened for that customer.  This gives my application more of a web site feel and reduces the number of command buttons crammed onto my form. 

To create a hyperlinked label, simply add a label to the form, set the properties, and add an onClick event.  The following is an example:

Label Object

  • Name: lblCustomer
  • Caption: Customer
  • Hyperlink Address: #
  • Control Tip:  Click to view/edit the customer details.

Private Sub lblCustomer_Click()
    DoCmd.OpenForm "frmCustomer", , , "CustomerID=" & Me.CustomerID
End Sub

Hyperlink Label

Prompt users when they exit/quit the application

Almost every user will mistakenly close the application when they did not want to (some more often then others). For whatever reason there is almost always a grunt involved. (Note to all you developers, a grunt = frustration, this the users way of telling you they need help or want a fix. As funny as this may sound, it is true, interview the user and take notes.) The inadvertent close can easily be eliminated with a simple procedure triggered on the Unload event of the application’s Main Menu.

Private Sub Form_Unload(Cancel As Integer)
    Dim vResponse As Variant
    vResponse = MsgBox("Do you wish to quit the application?", 36, "Confirm Quit")
    If vResponse = vbNo Then
        Cancel = True
    Else
        Application.Quit
    End If
End Sub

Auto Enter Dates

Use the Date() or Now() function in the default value of date/time fields on Forms so the user does not have to enter them manually.  If the date/time field should be blank initially, but requires entry at a later point in time, then allow the user to automatically enter the values by double licking the field.

Private Sub YourField_DblClick(Cancel As Integer)
    Me.YourField = Now() ' Date & Time
    'Me.YourField = Date() 'Date Only
End Sub