Microsoft Access 2010 Bible

Part IV: Professional Database Development

1010

Unlike toolbars and menus in older Access versions, Access 2007 and 2010 support a single rib-

bon. All of the older versions of Access (version 2003 and earlier) had multiple toolbars and

menus, and Access automatically swapped toolbars and menus, depending on the current task per-

formed by the user. Access 2003, for instance, included a total of 29 different toolbars, many of

which were virtually identical except for a few controls here and there. The menuing system in

Access 2003 was similarly complex, with many different menu bar configurations, all dependent

on the user’s current activity.

Access 2007 and 2010 perform similar magic on the ribbon. The ribbon automatically transforms

to support the user’s current activity. For instance, when you’re working with a table in Datasheet

view, the ribbon displays controls for filtering, searching, and sorting datasheet fields, whereas

opening a report in Print Preview mode causes the ribbon to show controls for printing and adjust-

ing margins. Access takes care of all of the complexity of rearranging the controls on the ribbon to

suit the current task.

The older CommandBars model (see Figure 29.1), although complex and somewhat difficult to

work with, featured a complete object model that included several different object types, with

properties, methods, and events. Although a considerable amount of work was involved in build-

ing CommandBar-based toolbars and menus, a developer working with CommandBar objects ben-

efited from IntelliSense and online help that documented each type of CommandBar control.

FIGURE 29.1

Developers working with Access CommandBars were limited in their choice of controls.

In addition to the difficulty of programming the complex CommandBar model, CommandBar-

based toolbars and menus were somewhat limited in their abilities. Because of their rather “flat”

construction, many developers had to resort to deeply nested menus and toolbars buttons that

didn’t do much more than open dialog boxes that actually performed the task the user required.

Many users complained about the difficulty they had learning how to use custom menus, especially

if they were not particularly well-planned and constructed.

In addition, some users had tremendous trouble with movable toolbars and menus. By default, the

CommandBar objects in previous versions of Access were not only movable, but they could also be

docked at the top, bottom, or either side of the main Access screen. Users often complained that,

after they accidentally moved a toolbar or menu, it would “stick” to one side or the other of the

main Access screen, and they couldn’t figure out how to move it back to its original location. Also,

even though the convention was to always place a menu CommandBar above a toolbar

CommandBar, it was easy to swap these positions, contributing to a user’s confusion.

The ribbon (see Figure 29.2), which is shared by all of the Office applications, is an innovative

approach to dealing with the problem of flat toolbars and menus. Perhaps the first thing a new