[Contents] [Index] [Next] [Previous]

Mouse-Based Navigation


In mouse-based navigation, the mouse is used to move the focus among controls. If an implicit focus policy is in use, the keyboard focus simply follows the mouse pointer, and no other explicit action is required to change the focus.

With an explicit focus policy, pressing BSelect on a component must move focus to it, except for components that are used to adjust the size and location of other elements, such as ScrollBars. Pressing BSelect on these components need not move the focus. If not, after the mouse has acted on the component, the focus should remain on the component that previously had it. Pressing BSelect will also generally perform some selection or activation operation. Clicking BSelect on an activatable component can move focus to it without any other effect.

The only exception to the simple model of pointer navigation is a Menu system because Menus are not available on the screen until activated. Activating a Menu causes it to be shown on the screen. There are three types of Menus: Pulldown Menus, Popup Menus, and Option Menus. The MenuBar is also a special kind of Menu. A Menu system consists of all the Menus cascading from a single CascadeButton, OptionButton, or Popup Menu. The MenuBar system consists of the MenuBar and all of its associated Menus.

A Pulldown Menu is generally activated by pressing BSelect on a CascadeButton, which displays the Pulldown Menu. A Popup Menu is generally activated by pressing BMenu in an area with a Popup Menu, which displays the Popup Menu. An Option Menu is generally activated by pressing BSelect on an OptionButton, which displays the Option Menu. A Pulldown Menu pulled down from a CascadeButton within a Pulldown, Popup, or Option Menu is called a Cascade Menu. A MenuBar is generally activated by moving the input focus to the MenuBar. Since a MenuBar is always visible, activating the MenuBar does not change its appearance. Navigating to a Menu is equivalent to activating a Menu.

Menus are activated in one of two ways: spring-loaded or posted. Spring-loaded means that the Menu is removed when the mouse button that activated it is released. Posted means that the Menu is not removed when the mouse button that activated it is released, but must be explicitly removed by another user action. BSelect Press with the pointer on a Menu must activate the Menu in a spring-loaded manner. If the pointer is in an element with an inactive Popup Menu and the context of the element allows a Popup Menu to be displayed, BMenu Press must post (activate) the Menu in a spring-loaded manner. Note that the availability and contents of the Popup Menu can depend on the location of the pointer within the element, the contents of the element, or the selection state of the element. In the case where a Popup Menu can be posted by both an element and an element contained within it, the Popup Menu of the internal element must be posted. Once a Popup Menu is posted, BMenu must behave just as BSelect is described for any Menu system. BSelect must also be available from within a posted Popup Menu system, and must behave just as in any Menu system. BSelect Release within a spring-loaded Menu system must activate the button under the pointer at the time of the release. If the release is on a CascadeButton or OptionButton and the associated Cascade Menu was already posted at the time BSelect was pressed, it should be unposted; otherwise, the associated Cascade Menu must be posted.

Whenever any Menu is popped up or pulled down, the location cursor must be placed on the Menu's default entry, or on the first entry in the Menu if there is no default entry. Support for default entries in Menus is optional.

A spring-loaded Menu must be removed when the mouse button that activated it is released, except when the button is released on a CascadeButton in the Menu hierarchy. While a spring-loaded Menu system is popped up or pulled down, moving the pointer within the Menu system must move the location cursor to track the pointer. If the pointer rests on a CascadeButton, the Menu must be pulled down and must also become traversable. The Menu must be removed, possibly after a short delay, once the pointer moves to a Menu item outside of the Menu or its CascadeButton. If the Menu system is part of a MenuBar, moving the pointer to any other element on the MenuBar must unpost the current Menu system and post the Pulldown Menu associated with the new element. Releasing the button must activate any component in the Menu system, including a CascadeButton. Note that releasing the mouse button during a spring-loaded Menu operation in a CascadeButton, even a CascadeButton in the MenuBar, causes the associated Menu to remain posted. BMenu Click with the pointer in an area with a Popup Menu that was not previously posted must activate the Menu in a posted manner. BMenu Release with the pointer in an area with a Popup Menu that was posted prior to the associated BMenu Press should unpost the Menu.

A posted Menu remains visible until explicitly unposted. The keyboard focus model is forced to explicit, and the Menu system can be traversed using the keyboard as described later in this section.

If a mouse button is pressed outside of the Menu to unpost the Menu, the button press can also be treated as follows:

If the button press that unposts a Menu is not also passed to the underlying component, subsequent events up to and including the button release must not be passed to the underlying component.

Once a Pulldown or Option Menu is posted, BSelect Press in the Menu system must cause the Menu to behave as a spring-loaded Menu. Once a Popup Menu is posted, BSelect Press or BMenu Press in the Menu system must cause the Menu to behave as a spring-loaded Menu. Because of this, the pointer-driven activation behavior of spring-loaded Menus fully describes pointer-driven activation behavior in Menus.