Users generally have two different input devices available: keyboards and mice.
The widget that is receiving mouse events is referred to as the active widget. Generally, it's the widget that the mouse is hovering over. Things get a bit more complex when a drag operation is involved.
In a drag operation, a control may be allowed to "capture" the mouse, in which case, the widget that has captured the mouse can use the information to perform various actions, such as move a scrollbar or slider, even if the mouse is outside the range of the widget.
Drag operations may also involve widgets the mouse is passing over. Releasing the mouse button over an object indicates a drop action, and the widget can perform an action based on that.
I haven't currently implemented any drag and drop operations in the UI yet.
The widget that is receiving keyboard events is referred to as the widget with focus. A widget can get focus by clicking on it, or by using Tab or Shift+Tab to traverse to a different widget. The widget will continue to receive keyboard event, even if the mouse is no longer hovering over it.
A widget can accept mouse events, but still not accept focus. An example of this is the decoration widgets in a window dialog. You can't navigate to them via a Tab key, but you can move the mouse over them, and they will respond to hover and click events.
There are GetFocus and LoseFocus events when focus is gained and lost by a widget, and Enter and Leave events when the mouse passes over a widget.
I won't bore you with the specific details of bugs I've been tracking down relating to the GUI. But it's important to get these things right, or widgets remain "stuck" in the wrong state.
WordPress.com
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.