diff -r 42e9659b68d1 -r 41890dfa56f5 org.symbian.wrttools.doc.WRTKit/html/WRTKit_Control_states-GUID-f98575ac-f913-466d-a790-0ff0207463a3.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/org.symbian.wrttools.doc.WRTKit/html/WRTKit_Control_states-GUID-f98575ac-f913-466d-a790-0ff0207463a3.html Thu Mar 04 15:42:37 2010 -0800 @@ -0,0 +1,144 @@ + + + + + + + + + + + + + + +Control states + + + + + +

+Control states

+ +
+ +

+ + Controls can be in a number of different states. Some of the states are specific + to a particular type of control (e.g. whether a checkbox is checked) and some + are common to all controls. Some states can be explicitly set while others are + implicit based on some user action (e.g. moving the pointer over a control). + The states can be retrieved using "getter" functions and in cases when a state + can be explicitly set there is a "setter" function that allows the state to be + manipulated. The following presents the common control states. +

+ +

+Focusable

+ + +

+ + The focusable state is a boolean (i.e. true or false) value that indicates + whether the control can receive the focus and receive input or not. Some + non-interactive controls like labels are never focusable, others are focusable + unless the control has specifically been disabled, and some are always + focusable. E.g. textfields can be focused even when disabled in order to be able + to copy text from them to the clipboard. +

+ +
+ +

+Focused

+ + +

+ + The focused state is a boolean value that specifies if a control is currently + selected for interaction. The focused typically changes implicitly through user + actions like moving the 4-way controller, however the focus can also be + explicitly set. Unlike other states, setting the focus to a control is more like + a request than an absolute command because it is not always possible to actually + set the focus to the control to which it is requested. For example if a control + is not focusable or not visible on the screen, the focus cannot be set to it. +

+ +
Figure 1. +Focused and unfocused FormButton controls + + +

+
+ +
+ +

+Hovering

+ + +

+ + Hovering means that the pointer arrow is over a control. It is always implicit + and changes based on pointer movement. The hovering state is a boolean value. + The hovering state is rarely needed outside a control itself, which uses it to + determine how the control draws itself. +

+ +
+ +

+Enabled

+ + +

+ + Controls are always enabled by default, but can be disabled to prevent + interaction. Disabling a control doesn't hide it but rather causes it to be + displayed in some way (typically with dimmer or duller colors) that indicates to + users that it cannot be used. Toggling the enabled state is always an explicit + action. The enabled state is a boolean value. Note that toggling the enabled + state can have an effect on other things. Focus is typically lost from controls + that are disabled and they become non-focusable. +

+ +
Figure 2. +Enabled and disabled FormButton controls + + +

+
+ +
+ +

+Activated

+ + +

+ + Certain controls like textfields cannot be interacted with despite being + focused. Instead the focus merely indicates that they are selected for + interaction. In order to actually interact with them they have to be "activated" + by pressing a selection button. The reason for this is that the same 4-way + controller keys are used for navigating between controls and within a control. + When a control such as a textfield is activated, all key presses are consumed by + the control. Activation of a control is transparent to the WRTKit and due to + this cannot be queried nor commanded. Also note that activation is not needed on + PC computers and thus will not occur when testing a WRTKit user interface in a + PC browser. +

+ +
+ +
+ +
+ +
+ + + \ No newline at end of file