Computer graphics processing and selective visual display system – Display driving control circuitry – Controlling the condition of display elements
Reexamination Certificate
2000-06-26
2004-01-13
Luu, Sy D. (Department: 2174)
Computer graphics processing and selective visual display system
Display driving control circuitry
Controlling the condition of display elements
C345S215000, C345S215000
Reexamination Certificate
active
06677962
ABSTRACT:
TECHNICAL FIELD
This invention relates generally to user interfaces and, more particularly, to methods and systems for manipulating user interfaces or controls that comprise user interfaces.
BACKGROUND
A “control” is a basic element of a computerized user interface and allows a user to interact with an application program, e.g. by adjusting the volume of a CD player application or by modifying the equalizer settings of a car or home stereo. Controls come in many shapes and sizes and, to date, have been traditionally designed by a control developer who decides what the control is going to look like, and how the control is to behave.(As an example, one type of control is a slider that can be engaged through a user input device, such as a mouse, and manipulated to adjust the operational parameters of a particular device. Another type of control is a push button that can be clicked on by a mouse to make a particular selection.
Control developers typically design their controls or control types to have a predefined appearance and behavior. After a control is designed by a developer, it is typically compiled, linked and shipped in a binary form. After such processing, the appearance and behavior of controls have not traditionally been manipulable, e.g. on a system-wide basis. That is, once the control developer decides on and implements a particular style and function of control, that style and function is essentially set for the system and is not capable of being changed.
There are systems in place in which application developers can develop their own sets of controls to execute in connection with their own defined applications. To this extent, it can be said that these types of controls vary in their appearance and behavior as between different applications. If a computer system executes these different applications, the system's users will be exposed to the different controls for each of the different applications that they execute. Because the controls are all different in appearance and behavior, there is no consistency between the user interfaces. This can very easily give rise to user confusion and degrade the user's experience. As an example, consider a simple slider control. One application developer might design a slider control to have a very different appearance and function than another application developer's slider control. Hence, when a user executes the applications developed by these developers, they are presented with very different versions of what should be easily understandable, standardized controls.
It would be highly desirable to be able to manipulate the appearance and, in some instances, the behavior of controls after the controls have been developed by a control developer so that the controls are implemented on a system-wide basis. This way, any applications that execute on a system and use a particular type of control would use the same appearance-modified or behavior-modified control.
For example, consider the case of an original equipment manufacturer (OEM). OEMs, such as hardware manufacturers, might manufacture a piece of hardware that utilizes a graphic user interface such as a slider or various push buttons. The software that is utilized or embedded in the hardware system might only provide controls having a predefined appearance that is considered by the OEM to be very bland. What the OEM really desires is a way to uniquely position their product so as to distinguish their product from other OEMs. One way to do this might be to manipulate the controls or UI so that the controls or UI identify the OEM as the originator of the product. To date, however, there has been no effective way to do this other than, perhaps to specially program the OEM's products to have a unique interface, including appearance and behavior.
This invention arose out of concerns associated with providing systems and methods for UI control manipulation, particularly after the control has been initially designed by a control designer.
SUMMARY
The described embodiments present methods and systems for manipulating user interface (UI) controls after the control has been designed by a control designer. Flexibility is provided through an architecture that enables controls to be manipulated or branded after they are developed. Advantageously, manipulation takes place on a system-wide basis so that different applications that utilize a common control present the same appearance-manipulated or behavior-manipulated control to the user. One particularly advantageous application of the described embodiments provides original equipment manufacturers (OEMs) the ability to brand their products, e.g. consumer embedded products, with a distinctive and identifying brand through the use of unique controls.
In the described inventive approach, the notion of a style class or style class object is introduced as a mechanism by which individuals other than the control developer, e.g. OEMs, can manipulate the appearance and behavior of a control after it has been developed by the control developer.
A style class object, in the described embodiment, is defined as a programming object that supports an interface that is defined by a control developer for a particular control. The interface provides all of the function calls that are necessary for imparting functionality to the particular control. Style class objects can be written or defined by third parties other than control developers, and essentially define the unique appearance of the control, subject to supporting the interface that was originally defined by the control developer.
Style class objects are utilized in connection with an inventive architecture that promotes flexibility in control appearance and behavior. In an exemplary architecture, different control classes are defined, each of which represents a particular type of control, e.g. a slider control class, a push button control class, and the like. Each control can have multiple styles associated with it. A style associated with a control class uniquely defines the type of control that is ultimately displayed (e.g. horizontal sliders and vertical sliders are both different styles of a control defined by a slider control class).
In the described embodiment, data that defines each control class is kept in a location that organizes the controls by control class. An exemplary location is a system registry where the control classes are organized by class IDs (CLSIDs) that are uniquely associated with each control. For each CLSID, there are associated styles that can be flagged for the particular control. The style of a control and its ultimate layout or position within a UI is defined by a control developer when the control is initially developed. Also in the system registry is data that references one or more style class objects. In the described embodiment, this data is embodied as class IDs (CLSIDs) for each of the style class objects.
When a control having a particular style is created, code executing on the system consults the system registry and locates the control class and style that is associated with the particular control. In addition, the code locates, for the particular style, the CLSID of a style class object that has been defined to control the appearance and behavior of the control. The style class object is instantiated and all function calls that are generated by a user are now made to the instantiated style class object. The style class object contains code that enables the control to be rendered and presented to the user in a unique way. Having style class objects provides a first level of indirection that enables uniquely designed controls to be presented to a user.
In another embodiment, the concept of a theme is introduced and is implemented by a second level of indirection.
A theme is essentially a mechanism that allows the overall appearance of the user interface to be changed. In the described embodiment, a theme is embodied by a registry entry that defines a “current theme”. A theme is essentially a collection of related appearances for all of
Lee & Hayes PLLC
Luu Sy D.
Microsoft Corporation
LandOfFree
Methods and systems for manipulating user interface controls does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Methods and systems for manipulating user interface controls, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Methods and systems for manipulating user interface controls will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3214756