Abstract: Various different output devices (e.g., printers, display devices) can be used to output content on various different substrates (e.g., paper, projector screens, painted walls or wallpaper). A data store stores output metadata for various output device and substrate combinations. The output metadata for an output device and substrate combination describes various different aspects of how that output device is to output color on that substrate. A computing device coupled to an output device obtains an identifier of the output device and an identifier of the substrate. The computing device communicates uses these identifiers to retrieve from the data store (e.g., directly or via a service) the output metadata for the output device and the substrate. The computing device uses the output metadata to generate output parameters for use when outputting content to the substrate.

Abstract: Various different output devices (e.g., printers, display devices) can be used to output content on various different substrates (e.g., paper, projector screens, painted walls or wallpaper). A data store stores output metadata for various output device and substrate combinations. The output metadata for an output device and substrate combination describes various different aspects of how that output device is to output color on that substrate. A computing device coupled to an output device obtains an identifier of the output device and an identifier of the substrate. The computing device communicates uses these identifiers to retrieve from the data store (e.g., directly or via a service) the output metadata for the output device and the substrate. The computing device uses the output metadata to generate output parameters for use when outputting content to the substrate.

Abstract: A new form of DHTML behaviors, called ˜Element Behaviors,” wherein a behavior component is bound to an HTML element, and not just attached to the element as with attached behaviors. A special processing instruction is used to import the Element Behavior into a Web page. Upon parsing the Web page, the Element Behavior is initialized as soon as it has been downloaded and parsed. This immediate initialization makes the Element Behavior declaratively available to bind synchronously to the element(s) it is modifying. A viewLink is a feature of Element Behaviors that permits encapsulation of a behavior component file (e.g., an HTC file) so that the structure of the HTC file is transparent to a Web page (˜primary document”) to which the HTC file is linked, but the content of the HTC file may be displayed in the primary document.

Abstract: A network storage system may receive the contents of a storage device attached to a client device to the network storage system. The network storage system may then redirect access to the contents of the client device to the network storage system. The storage device may then be removed or repurposed. Storage device management may be performed by the client device or the network storage system. A policy may be used to define under what circumstances the contents of a storage device may be moved to a network storage system, or data movement may be initiated by a user. Any access permissions or other metadata associated with files on the original storage device can be preserved.

Abstract: A data collection system may instrument and collect data from arbitrary executable code by loading the executable code into memory and instrumenting the code according to monitoring conditions. The instrumentation may include pointers or bindings to a data collector that may gather and store information when the monitoring condition exists. A display module may allow a programmer to browse the results. The data collection system may operate on any type of native code or intermediate code and may operate with or without symbol tables.

Abstract: Aspects of the subject matter described herein relate to detecting the ready state of a user interface element. In aspects, a synchronization object is created to indicate when a user interface element is ready. Data is then loaded into the user interface element. After the data is loaded, an indication is made via the synchronization object that the user interface element is ready. After this occurs, a thread waiting on the synchronization object may interact with the user interface element with confidence that the user interface element is ready.

Abstract: Aspects of the subject matter described herein relate to a page flow framework. In aspects, a page flow engine includes logic to navigate between pages. To make its determination of what page is next, the page flow engine uses an indication of the current page and may also use properties associated with the pages. These properties may be filled in as a user enters values on the pages, for example. The page flow engine does not need any additional information to determine the next page besides the current page and the properties. The page flow engine may also store the pages visited in a travel log. This may be used to return previous pages. The page flow engine allows the page flow logic to be removed from the pages and placed in a centralized component. This simplifies creation and maintenance of page flow.

Abstract: In aspects, object types are placed in a task repository and controls register with the task repository for notification when a different object type is selected. When a different object type is selected, the task repository is notified of the object type. In response, the task repository determines a list of one or more tasks associated with the selected object type. The task repository then notifies controls that have registered for notification and passes the list of one or more tasks. Using the list and the information included in the tasks, controls may rebuild their portion of a user interface. When a user or process indicates that the actions associated with an element are to be performed, the element calls the task repository and indicates a task to perform. In response, the task repository executes the actions associated with the task.

Abstract: Aspects of the subject matter described herein relate to a page flow framework. In aspects, a page flow engine includes logic to navigate between pages. To make its determination of what page is next, the page flow engine uses an indication of the current page and may also use properties associated with the pages. These properties may be filled in as a user enters values on the pages, for example. The page flow engine does not need any additional information to determine the next page besides the current page and the properties. The page flow engine may also store the pages visited in a travel log. This may be used to return previous pages. The page flow engine allows the page flow logic to be removed from the pages and placed in a centralized component. This simplifies creation and maintenance of page flow.

Abstract: Aspects of the subject matter described herein relate to validating properties. In aspects, a property is associated with one or more validators. Each validator includes actions to take to determine whether a feature of the property is valid. Multiple validators may be executed for a single property. A group of validators may be identified by an identifier. In addition, properties may be grouped into collections which may be grouped into other collections and so on. Each collection may also be associated with one or more validators to validate properties within the collections.

Abstract: Aspects of the subject matter described herein relate to detecting the ready state of a user interface element. In aspects, a synchronization object is created to indicate when a user interface element is ready. Data is then loaded into the user interface element. After the data is loaded, an indication is made via the synchronization object that the user interface element is ready. After this occurs, a thread waiting on the synchronization object may interact with the user interface element with confidence that the user interface element is ready.

Abstract: A new form of DHTML behaviors, called ˜Element Behaviors,” wherein a behavior component is bound to an HTML element, and not just attached to the element as with attached behaviors. A special processing instruction is used to import the Element Behavior into a Web page. Upon parsing the Web page, the Element Behavior is initialized as soon as it has been downloaded and parsed. This immediate initialization makes the Element Behavior declaratively available to bind synchronously to the element(s) it is modifying. A viewLink is a feature of Element Behaviors that permits encapsulation of a behavior component file (e.g., an HTC file) so that the structure of the HTC file is transparent to a Web page (˜primary document”) to which the HTC file is linked, but the content of the HTC file may be displayed in the primary document.

Abstract: A new form of DHTML behaviors, called “Element Behaviors,” wherein a behavior component is bound to an HTML element, and not just attached to the element as with attached behaviors. A special processing instruction is used to import the Element Behavior into a Web page. Upon parsing the Web page, the Element Behavior is initialized as soon as it has been downloaded and parsed. This immediate initialization makes the Element Behavior declaratively available to bind synchronously to the element(s) it is modifying. A viewLink is a feature of Element Behaviors that permits encapsulation of a behavior component file (e.g., an HTC file) so that the structure of the HTC file is transparent to a Web page (“primary document”) to which the HTC file is linked, but the content of the HTC file may be displayed in the primary document.

Abstract: Described is a computer networking-related technology by which an association is maintained between network account objects (e.g., for network users, computers, services and so forth) and a role template object for those types of account objects. The network account objects for a role may be located based on the association, and an administrative function such as propagating changes, generating reports, monitoring and/or enforcing compliance with the role template object and so on may be performed on those associated network account objects. Action information, such as a set of URIs referencing workflow assemblies containing tasks to perform, may be maintained in the role template object. Upon the occurrence of a lifecycle event (e.g., creation, reassignment to another role template object or deletion) that occurs to an associated network account object, a defined action comprising one or more tasks may be automatically taken via the association with the role template object.

Abstract: A dynamic SKU manager creates versions of programs with different feature sets without a recompilation of the products. Features are enabled either before shipping to a user, or after the user has a partially enabled product. A brand module creates an encrypted value for each version which is unique to the machine on which the program is installed. The encrypted value contains an identifier, a date, and a machine unique name. A query component is called by various components of the program to obtain information about features and capabilities of a currently installed program. It also keeps track of which SKUs are available, and need not be recompiled if no changes have been made to the available SKUs on the machine. The query component is dynamically loaded and unloaded each time it is needed.