Abstract: The described technology is directed towards a pre-child user interface element in a user interface tree that draws before the parent element draws, (and thus before any conventional child element of the parent draws). For example, based upon current state data such as whether the parent element has focus, the pre-child may draw a highlight or the like before (so as to be beneath) drawing the representation of the parent element, to indicate the focused state (or and/or other current state or states). The user interface tree maintains a property that it is composable because the parent user interface element code is independent of what any of its pre-child element or pre-children elements do when invoked.

Abstract: The described technology is directed towards data-driven navigation, in which a next navigation location depends on variable data associated with an interactive user interface element (rather than a fixed link). The data may be in a hierarchy of data models. A menu contains interactive navigation elements, each bound to a data model. A selected interactive navigation element results in locating a data model associated with the selected element. The data model is used to determine the next navigation location. Also described is hierarchical navigation to one item of a level as well as lateral and peer navigation.

Abstract: The described technology is directed towards having UI elements structured in a hierarchical configuration, in which parent and child UI elements communicate via a virtualization interface. A change to any parent UI element view propagates to each impacted descendant, e.g., each child, any children of that child and so on, whereby each child can manage virtualization and rendering based upon the change. Focus changes among the UI elements are also handled by propagating information via the virtualization interface.

Abstract: Determining the rendering of user interface (UI) elements, referred to as views, based upon styleable transitions between possible states of a view. Transitions may include animation, such as to smoothly enter a view into or exit a view out of a scene over a number of rendering frames. Transitions also may be applied to view state changes related to a UI element, such as to indicate hovered over, focused, listening (for speech), selected and/or pressed. View state changes also may be animated.

Abstract: The described technology is directed towards determining the rendering of user interface (UI) elements, referred to as views, based upon styles, in which styles comprise property values such as color value data, font data, border data, position data, and/or animation-related data applied to a view. A view object instance is returned upon request based upon an identifier that is used to select an unstyled view object and a style applied to that view object. The styles may be maintained as a fixed set of styles for a runtime session.

Abstract: The described technology is directed towards a platform-independent user interface (UI) system. Views and other objects at the platform-independent UI system level perform layout, scrolling, virtualization, styling, data binding via data models and/or readiness. Input handling and output to a display tree are also performed at this level. An abstraction layer processes the display tree into function calls to objects of the underlying platform to render visible output.

Abstract: The described technology is directed towards data-driven navigation, in which a next navigation location depends on variable data associated with an interactive user interface element (rather than a fixed link). The data may be in a hierarchy of data models. A menu contains interactive navigation elements, each bound to a data model. A selected interactive navigation element results in locating a data model associated with the selected element. The data model is used to determine the next navigation location. Also described is hierarchical navigation to one item of a level as well as lateral and peer navigation.

Abstract: Determining the rendering of user interface (UI) elements, referred to as views, based upon styleable transitions between possible states of a view. Transitions may include animation, such as to smoothly enter a view into or exit a view out of a scene over a number of rendering frames. Transitions also may be applied to view state changes related to a UI element, such as to indicate hovered over, focused, listening (for speech), selected and/or pressed. View state changes also may be animated.

Abstract: Determining the rendering of user interface (UI) elements, referred to as views, based upon styleable transitions between possible states of a view. Transitions may include animation, such as to smoothly enter a view into or exit a view out of a scene over a number of rendering frames. Transitions also may be applied to view state changes related to a UI element, such as to indicate hovered over, focused, listening (for speech), selected and/or pressed. View state changes also may be animated.

Abstract: The described technology is directed towards normalizing input received from various types of device types for providing the input to user interface (UI) elements in a unified way that reflects the invoke intent of the user. Input from different device types is classified as button input, pointer input or command input, and routed to a corresponding button provider, pointer provider or command provider. Each provider includes logic for communicating input data (e.g., events) to a UI element or elements. Based upon the input events, a UI element can execute a corresponding invoke handler to take an invoke action for that particular event.

Abstract: The described technology is directed towards determining the rendering of user interface (UI) elements, referred to as views, based upon styles, in which styles comprise property values such as color value data, font data, border data, position data, and/or animation-related data applied to a view. A view object instance is returned upon request based upon an identifier that is used to select an unstyled view object and a style applied to that view object. The styles may be maintained as a fixed set of styles for a runtime session.

Abstract: The described technology is directed towards a pre-child user interface element in a user interface tree that draws before the parent element draws, (and thus before any conventional child element of the parent draws). For example, based upon current state data such as whether the parent element has focus, the pre-child may draw a highlight or the like before (so as to be beneath) drawing the representation of the parent element, to indicate the focused state (or and/or other current state or states). The user interface tree maintains a property that it is composable because the parent user interface element code is independent of what any of its pre-child element or pre-children elements do when invoked.

Abstract: The described technology is directed towards determining the rendering of user interface (UI) elements, referred to as views, based upon styles, in which styles comprise property values such as color value data, font data, border data, position data, and/or animation-related data applied to a view. A view object instance is returned upon request based upon an identifier that is used to select an unstyled view object and a style applied to that view object. The styles may be maintained as a fixed set of styles for a runtime session.

Abstract: The described technology is directed towards a pre-child user interface element in a user interface tree that draws before the parent element draws, (and thus before any conventional child element of the parent draws). For example, based upon current state data such as whether the parent element has focus, the pre-child may draw a highlight or the like before (so as to be beneath) drawing the representation of the parent element, to indicate the focused state (or and/or other current state or states). The user interface tree maintains a property that it is composable because the parent user interface element code is independent of what any of its pre-child element or pre-children elements do when invoked.

Abstract: The described technology is directed towards sharing asynchronous (async) tasks between task chains, including in a way that prevents cancellation of lower-level chain entity from cancelling a shared async task. A shared async task is wrapped in multiplexer code that maintains lower-level entity identities as a set of listeners of the shared async task, and when a listener cancels, only removes that listener from the set of listeners so that the shared async task does not cancel as long as one listener remains in the set. Also described is optimization to share an async task, and wrapping tasks in cancel-checking code that prevents the task from running its work if the task is intended to be cancelled but is queued to run before the cancel request is queued to run.

Abstract: The described technology is directed towards determining the rendering of user interface (UI) elements, referred to as views, based upon styleable transitions between possible states of a view. Transitions may include animation, such as to smoothly enter a view into or exit a view out of a scene over a number of rendering frames. Transitions also may be applied to view state changes related to a UI element, such as to indicate hovered over, focused, listening (for speech), selected and/or pressed. View state changes also may be animated.

Abstract: The described technology is directed towards normalizing input received from various types of device types for providing the input to user interface (UI) elements in a unified way that reflects the invoke intent of the user. Input from different device types is classified as button input, pointer input or command input, and routed to a corresponding button provider, pointer provider or command provider. Each provider includes logic for communicating input data (e.g., events) to a UI element or elements. Based upon the input events, a UI element can execute a corresponding invoke handler to take an invoke action for that particular event.

Abstract: The described technology is directed towards a button repeat system that allows different repeat behaviors (e.g., interval times between repeats) to be customized for any view (user interface element) and for any button. A designer specifies an interval set comprising interval times to use in an associated view to repeat a button that is pressed and held. Using global information across views, a button that is pressed and held may continue to repeat as focus changes among views. The repeating may continue without needing to reset to the first interval time of the interval set of each view as focus changes, so that, for example, a rapidly repeating button does not appear to change its repetition rate as focus changes among views.

Abstract: The described technology is directed towards virtual input devices that take application program-directed input from automation and/or remote devices, such as over a network, instead of via actual user input via a physical device, for example. This allows an automation framework to insert input into an application program, such as for automated testing without modifying any of the application's other components. The virtual input devices may be object instances or the like that receive their input from function calls based upon the type of input and output events, e.g., to simulate keyboard input/output (I/O), mouse or other pointer I/O, voice, gesture, and other command I/O, and so forth.

Abstract: The described technology is directed towards normalizing input received from various types of device types for providing the input to user interface (UI) elements in a unified way that reflects the invoke intent of the user. Input from different device types is classified as button input, pointer input or command input, and routed to a corresponding button provider, pointer provider or command provider. Each provider includes logic for communicating input data (e.g., events) to a UI element or elements. Based upon the input events, a UI element can execute a corresponding invoke handler to take an invoke action for that particular event.