Computer graphics processing and selective visual display system – Display driving control circuitry – Controlling the condition of display elements
Reexamination Certificate
2001-04-03
2004-06-22
Bayerl, Raymond J. (Department: 2173)
Computer graphics processing and selective visual display system
Display driving control circuitry
Controlling the condition of display elements
C345S215000, C707S793000, C707S793000
Reexamination Certificate
active
06753885
ABSTRACT:
TECHNICAL FIELD
The present invention relates to a computer system and, more particularly, to a method, system and file format that facilitates creating and changing the visual style of displayed graphical components, such as controls.
BACKGROUND OF THE INVENTION
Computer users in both the business and home environment have become accustomed to using a computer with a graphical operating system. For example, many users operate computers having a Microsoft Corporation “WINDOWS” operating system thereon. Certain components of these graphical operating systems are known as “controls.” For example, a control may be an “OK” button, which is generally a rectangular button with “OK” written in it. By moving the cursor over the button and clicking on the mouse, a known operation will begin that is associated with the control. Many other controls exist, with examples including scroll bars, dialog boxes and sliders. Beyond controls, the graphical operating systems also draw, or render, other graphical components as needed on the display of the computer, such as the window frame, the minimize box and the close box, which may collectively be called “non-client” components.
There are two general kinds of controls in WINDOWS: standard and custom. Standard controls are provided by the operating system. The code to create, draw and operate standard controls is contained in the common control library (DLL), or in USER.dll, both of which are standard libraries provided as a part of WINDOWS. Custom controls are all other controls. Custom controls may be created by the manufacturer of the operating system or by third parties. The code for custom controls is contained in a corresponding separate library (DLL) or within an application.
Currently, when a graphical user interface component, such as a control, is used by an application, the application requests that an instance of the component be created. Following this, the operating system transmits a generic message to the component, instructing the component to render itself. The application plays a role in routing the message from the main window to the targeted control, but the control code performs the drawing. The application uses application programming interfaces (API's) to create and interact with the control. An API serves as a software interface to be used by other programs, much as the keypad serves as an interface to a calculator. An API is a fundamental concept of high-level programming. In high-level programming, a program often does not execute tasks by itself. Instead, the program asks some other program to execute these tasks. For example, programs frequently delegate various tasks to the underlying operating system. Continuing with the above example, an application delegates the rendering of a control to the control's code.
In the existing environment, when a generic rendering message is received by a control to draw itself, the control will draw itself using its own drawing software code. In this prior art environment, the control knows what it is supposed to look like, how it is supposed to behave, and can effectuate such a display on the user interface of the computer. Thus, the application may delegate all aspects of visual rendering to the controls, avoiding the need to contain software code to support the visual rendering of the control within the host application itself.
By utilizing the standard controls defined and rendered by the operating system, all controls will have the same appearance, regardless of the application. Users of graphical operating systems can change only a limited number of characteristics of the controls. In the “WINDOWS” operating system, a user can change the color scheme used to display the various controls and components on the monitor. The user can also select one of a number of fonts to be used by the controls and components. The user can also specify nonclient sizes that will control the sizing of the non-client areas. Thus, the colors, fonts and sizes of the controls and components may be changed. However, the basic appearance of the controls and components is dictated by the rendering software code within the control library containing the particular graphical component or control. In the prior art environment, to change the appearance of the controls or graphical components, the rendering software code must be altered. For example, if it is desired to change the appearance of the “OK” button, the rendering software code within the operating system DLL file containing the button control must be altered and the DLL file reconstructed at the binary level. If it was desired to render the button as an oval, the software code would have to be changed accordingly. Such an approach makes it difficult, if not impossible, for a computer user and for software manufacturers, to easily alter the appearance of the controls and graphical components.
In order to enhance the user experience of the computer, it would be desirable for the user to have the ability to change the overall “look and feel” of the graphical display by changing the overall visual appearance or “theme” of the various graphical components. In other words, it would be desirable if the user could change not only the color and font of the graphical components appearing on the monitor, but to change the appearance of those graphical components as well. For example, it would be desirable to be able to alter and direct the layout of the parts of a control, and to define the shape of a control or its parts. It would also be desirable to control all aspects of how a control or its parts are drawn. Because the controls and graphical components existing within the DLL file in the prior art environment are “hard coded” with their own rendering software code, it is difficult and cumbersome to change the appearance of all of the controls and components. To do so would require recoding each of the controls to achieve the desired appearance. If multiple visual styles were required, they would each have to be predefined and each “hard coded” into every control. Using the current approach, if a user interface designer desires to have a new “look” for a set of graphical components, the designer must communicate this desire to a programmer. The programmer will then attempt to appropriately code the components to achieve the look desired by the designer. The designer will then review the look and communicate any needed changes to the programmer. This process continues, often with multiple iterations, until the designer is satisfied with the look achieved. It can be seen that the above process is time-consuming and is limited by the communication between the designer and the programmer. It would be desirable to allow the designer to be able to perform the tasks necessary to achieve a specific look and to be able to revise the look achieved until the designer is satisfied. This would eliminate the revision time between the designer and the programmer and would give the designer more flexibility in the look achieved.
Certain prior approaches exist that attempt to address the above situation. However, these solutions do not allow all of the controls and graphical components of the entire system to be changed. Instead, the prior art approaches address only limited portions of the set of displayed components. This allows the appearance of some controls and graphical components to be altered, leaving the remainder unaltered. Further, the prior art approaches may suffer from poor performance and may lack the desired level of stability.
Accordingly, there is a need for an effective system, method and file format that allows a designer to efficiently create a visual style for a set of controls and graphical components that addresses the above drawbacks and deficiencies. Such a system and file format should allow a programmer or custom control author the flexibility to create new options for the controls and components, such that the designer has additional options. Adding a new control type or a new custom property does not require a change to the theme
Evans Christopher
Fernandez Roland L.
Raiz Gregory L.
Stoakley Richard W.
Tinling Aaron B.
Bayerl Raymond J.
Microsoft Corporation
Shook Hardy & Bacon L.L.P.
Vu Kieu D.
LandOfFree
System and theme file format for creating visual styles does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and theme file format for creating visual styles, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and theme file format for creating visual styles will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3339398