Patent Application
20070124686
Computer software applications may employ a graphical interface that facilitates user input and output. For example, an application may present a user with one or more windows representing different functional aspects of the application and/or representing different data that may be operated upon by the application. In addition, multiple applications may be present on a computer screen at the same time where the different applications are provided in different windows. Such operating systems also provide users with various options for inputting data including typing on the keyboard and using a mouse to click on menus, scrollbars, buttons, etc.
Although theoretically it is possible to have each application developer write all of the code necessary to present the user with a number of graphical elements, it is more often the case that the application developer uses tools for providing the graphical elements in connection with developing the application. The tools may be in the form of API calls made by the application code to present the various graphical elements and to receive user input through various graphic controls. The tools may be considered part of a presentation system which may be provided by the vendor of the operating system and/or by a third-party. The tools facilitate development of applications by eliminating the need for each application developer to reconstruct the code necessary to provide the graphical elements. In addition, the tools help to maintain a consistency of presentation for the graphical elements across different applications provided by different developers.
Some types of objects may have graphical elements associated with them. For example, a control object may have graphical elements associated with it that dictate how the control is presented to a user. In some cases the particular graphical element that is used may depend upon run time conditions, such as a user selected theme for a computer. It is possible to provide all of the graphical elements associated with an object in the same location as the object. Although such a scheme is relatively straightforward, there may be drawbacks, such as the inability to provide the objects and associated graphical elements separately (e.g., when updating the “look” of an application without modifying the functional application code). In addition, it may be desirable to share graphical elements among a plurality of objects. However, requiring that objects and associated graphical elements be provided in the same location would cause objects that share graphical elements to need to be provided in the same location, which in some cases may negate the efficiencies of sharing and/or simply not be practical in a given situation.
On the other hand, allowing objects and associated graphical elements to be provided in different locations may be difficult. When an object is accessed, it may be necessary to quickly and accurately access the associated graphical element even though the graphical element may be provided in a location different from the location of the object. Thus, it is desirable to provide a mechanism for accessing a graphical element of an object even when the graphical element is stored in a different location than the object.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Locating a graphical element associated with an object includes obtaining a key for the object, using the key to determine a particular data table containing the graphical element, and using the key to obtain an identifier for the graphical element within the data table. The custom graphical element may be graphical portions of a custom control, or the graphical representation for the whole custom control itself. The data table may be initially provided as a file.
Associating a particular graphical element with an object includes providing the graphical element at a particular location separate from the object, providing a key indicating the particular location and an identifier for the graphical element at the location, and associating the key with the object. The location may be a resource dictionary located within an assembly. The method may also include modifying the key to point to a different graphical element based on run time conditions, such as a user selected theme.
Drawing a graphical element associated with an object includes locating the graphical element, wherein the graphical element is at a location different from the object and after locating the graphical element, drawing the graphical element. Locating the graphical element may include obtaining a key for the object, where the key indicates a particular resource dictionary and a particular location within the resource dictionary.
Described herein are various technologies and techniques for facilitating accessing a graphical element associated with an object where the object and the graphical element are provided at different locations. Various embodiments are described more fully below with reference to the accompanying drawings, which form a part hereof, and which show specific exemplary embodiments for practicing various embodiments. However, other embodiments may be implemented in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete. Embodiments may be practiced as methods, systems or devices. Accordingly, embodiments may take the form of a hardware implementation, an entirely software implementation or an implementation combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.
The logical operations of the various embodiments are implemented (1) as a sequence of computer implemented steps running on a computing system and/or (2) as interconnected machine modules within the computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system implementing the embodiment. Accordingly, the logical operations making up the embodiments described herein are referred to alternatively as operations, steps or modules.
Referring to
The first set of objects 16 may be separate from the application 12 while the second set of objects 17 may be part of the application. The application 12 may interact with the first set of objects 16. There may be any number of other sets of objects (not shown) used by the application 12. A subset of objects within the sets of objects 16, 17 may use graphical elements. The sets of objects 16, 17 may represent any type of objects, including objects associated with graphical controls.
For particular objects of the sets of the objects 16, 17 that use graphical elements, the resource dictionary data elements 18, 19 may contain information that allows the presentation system 14 to draw the various graphical elements. The resource dictionary data elements 18, 19 represent any data in any appropriate format capable of storing graphical elements and providing access thereto in a manner that is consistent with the description provided herein. There may be a plurality of resource dictionary data elements (or the equivalent) in a plurality of different formats. Note that having the resource dictionary data elements 18, 19 be separate from the application 12, the presentation system 14, and the sets of objects 16, 17 allows for separately and independently defining the appearance of any graphical element handled by the presentation system 14. Accordingly, it is possible to independently change the appearance of an object by modifying the resource dictionary data elements 18, 19 without having to modify the application 12 or the presentation system 14 and without having to modify any objects within the sets of objects 16, 17. However, for other embodiments, it is possible to have a portion of one or more of the resource data dictionary elements 18, 19 be part of or integrated with one or more of the sets of objects 16, 17, the application 12, and/or the presentation system 14.
Referring to
In an embodiment herein, an integrated graphical unit includes any collection of graphical elements, such as a window and associated elements that may be presented to a user. Elements of an integrated graphical unit may be stored in a data structure (e.g., a tree) containing information indicative of each of the graphical elements (e.g., leaves of the tree). Thus, the integrated graphical unit 30 may be represented by a tree data structure having, as elements, data indicative of the window frame 32, the title bar 34, the stock control 36, and the custom control 38. Of course, other data structures and indeed other mechanisms may be used to maintain information for an integrated graphical unit.
The presentation system 14 may handle drawing graphical elements associated with any number of resource dictionary data elements using a mechanism that associates graphical elements and objects provided in different locations. In an embodiment herein, objects, applications, and/or resource dictionary data elements may be provided in executable code units such as assemblies, which may be loaded into the memory of the computer system on which the application 12 is run.
Referring to
Referring to
In an embodiment herein, the theme of a computer system may determine the overall look of the system, including the rendering of windows, icons, menus, etc. In some instances, the keys may be configured to account for theme changes so that the keys are not modified based on theme changes even though the graphical view of the application changes for the user when the theme changes. In those embodiments, the keys may be configured to automatically point to a different resource file (described elsewhere herein) in response to a change in the theme. Of course, it is possible to also have an alternative embodiment of the system where changes in the theme cause changes to the keys.
Following step 62 is a step 64 where a target ID is obtained from the key. In an embodiment herein, the target ID represents the location (e.g., particular resource dictionary) of the graphical element. The location could be in any appropriate form, including an identifier for a resource dictionary that may or may not be located within an assembly (dll or executable file) or in some other location within a computer system. The target ID may indicate a particular assembly (executable) in which the appropriate resource dictionary is located. Following the step 64 is a step 66 where a resource ID is obtained from the key. In an embodiment herein, the key associated with an object contains a target ID identifying a location of a graphical element and contains a resource ID indicating a particular resource (graphical element) within the location (e.g., the particular entry in the resource dictionary). In an embodiment herein, the resource ID includes a number appended to a base identifier corresponding to the object so that, for example, an object identified as “XYZ” may have graphical elements associated therewith with resource ID's of “XYZ01”, “XYZ02”, etc. Of course, any one of a number of other appropriate techniques may be used to provide unique identifiers.
In an embodiment herein, a single instance of an object will only have a single graphical element associated therewith at any particular time where the particular graphical element may be changed by changing the key and/or by changing the graphical element to which the key points. However, other schemes are possible where multiple graphical elements may be associated with a single object (single key) at any particular time. For example, a single object may have a corresponding key that points to different graphical elements according to a user-selected theme. In any event, a resource dictionary may contain multiple versions of a graphical element that differ according to the particular resource ID. Following the step 66 is a step 68 where the graphical element is accessed to obtain the information necessary to draw the corresponding object. Following step 68, processing is complete.
Referring to
In an embodiment herein, each of the resource files 74-76 represents a particular theme (e.g., “classic”) and the contents of each of the resource files 74-76 include entries for each graphical element that may be modified in response to a theme change. Thus, an application developer could create code that includes an object (either a custom object or one that is provided with the presentation system 14) and could then populate each of the resource files 74-76 with data indicating how the object should look under different conditions. Then, depending on the run time conditions, a key associated with the object may be provided to indicate which directory, which of the resource files 74-76 in the chosen directory, and which graphical element (resource) therein to use.
Of course, other techniques for arranging resource files and corresponding resource dictionaries may be used, including providing all resources (graphical elements) in a single file (source) that is converted into a single assembly. It is also worth noting that one or more resource dictionaries may be included in the assembly that includes the application and/or the assembly that includes at least some of the objects. So it may be noted that one or more resource dictionaries may actually exist in one or more assemblies used by an application. Thus, by using a key as explained herein, it becomes possible to locate a graphical element resource in a resource dictionary that exists in an assembly external to the one in which the object associated with that key exists.
Referring to
The operations described herein may be referred to variously as steps, operations, structural devices, acts or modules. However, it is noted that these operations, structural devices, acts and modules may be implemented in software, in firmware, in special purpose digital logic, a computer readable medium having computer executable instructions, and any combination thereof without deviating from the spirit and scope of the system described herein. Furthermore, it should be appreciated that while a particular order of operation is set forth with respect to the logical operations illustrated herein, other orders of operation are possible, unless indicated otherwise or apparent from the context.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
