KR20060059335A - System and method for controlling user interface properties with data - Google Patents

Abstract

Described is a system and method for controlling user interface (UI) properties with data. A computing device (100) having an application (202) is separated into independent parts, a logic portion and a UI portion. The logic portion manipulates data values within the application. The UI portion is responsible for displaying UI properties. A binding specification describes a relationship between the UO property and data value. The binding specification is used by system level code to determine the manner in which it is notified when the data value undergoes a change and the manner in which it directs the UO portion to reflect the change in the UI property. The binding specification identifies a source data item, a path to the data value in the source data item, a target UI element, and the UO property on the target UI element. The binding may be specified using code or markup language.

Description

SYSTEM AND METHOD FOR CONTROLLING USER INTERFACE PROPERTIES WITH DATA}

This application is a PCT application filed by Microsoft Corporation on May 17, 2003, filed internationally in the United States, and designated for all countries except the United States.

The manner in which the information is presented to the user affects the user's ability to understand and understand the information. In computer displays, it has become common to add emphasis to information using colors, font styles, and the like. This emphasis makes it easier for users to grasp the importance of information. Code (user interface) that handles the representation of information and code that performs application logic on that information are typically tightly coupled. For example, logic directly assigns data to user interface attributes (color, font, position, size). Therefore, when there is a change in the user interface, the logic must also change. For example, in the case of a text box, the user interface code listens to determine whether the text has changed at the time of change, and the user interface code checks the changed text and then displays the changed text. This tightly coupled user interface and logic results in inherently weak code. Maintaining this weak code is costly and time consuming.

The present invention relates to a system and method for controlling a user interface in accordance with data. The present invention, along with user interface and application logic, separates data by providing a mechanism for associating that data with the user interface. The present invention allows user interface designers and application writers who write application logic to work independently. Neither the designer nor the author need to understand each other's code, nor will they affect each other's code development. The invention also makes it very easy to change the user interface. For example, when a new and more user-friendly user interface platform becomes available or the user interface designer wants to change the appearance of the application, the designer does not need to change the application logic. In addition, the mechanism for associating data with the user interface is dynamic. This allows any change in the data to be automatically reflected in the representation. In addition, any input from the user through the user interface can automatically update the data. The present invention allows associations not only to the data display aspect of the user interface (eg text), but also to the visual aspect (eg background, font size, etc.), thereby improving data explanatory and visually. I can express it flexibly. For example, negative numbers may be displayed in red or may indicate that an arrow points upward when the stock price rises.

Therefore, according to the present invention, the application can be divided into independent parts of the logic area and the UI area. Logic regions manipulate data values within the application. The UI area is responsible for the representation of the data. The binding specification describes the relationship between UI properties and data values. This binding specification is used to determine how the system level code is to be notified when a data value undergoes a change and how to instruct the UI area to reflect that change in UI attributes. The binding specification identifies the source data item, the path of the data value of the source data item, the target UI element, and the UI attribute of the target UI element. This binding can be specified using code or markup language.

1 illustrates an example computing device that may be used in an exemplary implementation of the invention.

2 is a functional block diagram illustrating one embodiment of controlling user interface attributes with data in accordance with the present invention.

3 is a logical flow diagram illustrating a process of binding to a user interface attribute having a data value in accordance with one embodiment of the present invention.

4 is some exemplary syntax for associating user interface attributes with data in accordance with an embodiment of the invention.

The present invention provides a system and method for controlling a user interface in accordance with data. The present invention separates user interface and application logic by providing a mechanism for associating data with a user interface. As will be described in detail below, this separation of user interface and data, depending on its associated logic, allows different groups of developers to work independently without affecting the development of other groups of code both in the user interface and logic. To be. In addition, in the following detailed description, the present invention provides a system and method for automatically transferring values from a data source to a user interface or the like. Throughout the discussion below, the term "data binding" refers to a process of associating data values with a UI attribute, sending and updating data values, and the like.

Example Computing Environment

1 illustrates an example computing device that may be used in an example implementation of the invention. Referring to FIG. 1, in a very basic configuration, computing device 100 typically includes at least one processing unit 102 and system memory 104. Depending on the exact configuration and type of computing device 100, system memory 104 may be volatile (such as RAM), nonvolatile (such as ROM, flash memory, etc.) or any combination of both. System memory 104 typically includes an operating system 105, one or more program modules 106, and may include program data 107. Examples of program module 106 include browser applications, financial management applications, word processors, and the like. This basic configuration is shown by these components within dashed line 108 in FIG. 1.

Computing device 100 may have additional features or functionality. For example, computing device 100 may also include additional data storage devices (removable and / or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage devices are shown in FIG. 1 as removable storage 109 and non-removable storage 110. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method and technology for storage of information, such as computer readable instructions, data structures, program modules or other data. System memory 104, removable storage 109 and non-removable storage 110 are all examples of computer storage media. Computer storage media may include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, DVD, other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices or other magnetic storage devices, or computing device 100. Including, but not limited to, any other medium that can be accessed by and used to store desired information. Any such computer storage media may be part of computing device 100. Computing device 100 may also have input device (s) 112, such as a keyboard, mouse, fan, voice input device, touch input device, and the like. Output device (s) 114 such as displays, speakers, printers, etc. may also be included. These devices are well known in the art and need not be described in detail herein.

Computing device 100 may also include a communication connection 116 that allows device 100 to communicate with other computing devices 118, such as on a network. Communication connection 116 is one example of communication media. Communication media can typically be implemented by computer readable instructions, data structures, program modules, or other data in modulated data signals, such as carrier waves or other transmission mechanisms, and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, communication media includes, but is not limited to, wired media such as a wired network or direct wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. The term computer readable media as used herein includes storage devices and communication media.

Example implementation

2 is a functional block diagram illustrating one embodiment of a system 200 for controlling user interface attributes having data in accordance with the present invention. System 200 includes an application 202, a platform 220, and a data source 230. The application 202 may be one of the applications 106 on the computing device 100 shown in FIG. 1. Application 202 includes code (also referred to herein as logic 204) to manipulate data values (eg, source data values 238). In general, logic 204 performs verification of data values and updates data values. The data value (eg, data value 238) represents the content of an attribute (ie, data source attribute) of the data item (eg, data item 232). Data item 232 is located within a data source (eg, data source 230). Each data source 230 may include several data items, each data item having one or more attributes in which the source data value is stored. Logic 203 may manipulate data values from a plurality of data sources. Data sources can include XML documents, objects, datasets, and the like. As will be described in more detail below, each attribute of a data item is used to control a user interface (UI).

The application 202 also includes code (referred to herein as the user interface 206) to represent the information. User interface 206 includes several user interface elements (eg, user interface element 208). Each user interface element 208 includes one or more attributes (eg, UI attributes 210 and 212), such as displayed text, color, font, position, size, and the like. Then, as will be described in detail below, these UI attributes 210 and 212 are associated with one or more data values 238 and 242 in accordance with the present invention. In general, this association takes place through the binding engine 224 in the platform 220. Platform 220 represents a system layer of services, such as an operating system, a virtual engine, or the like. Platform 220 includes an attribute engine 222 that is responsible for maintaining hierarchical information appended to data values 234 and 242 and updating attributes associated with the data values. Although binding engine 224 and attribute engine 222 are shown as separate components, those skilled in the art will appreciate that the functionality provided by each may be included in one component without departing from the present invention. Will recognize.

The association (ie, binding) of the data values 238 and 242 with their UI attributes 210 and 212 is shown in FIG. 2 by dotted lines from the data values to the UI attributes (hereafter referred to as bindings 226 and 228). Called). In the discussion that follows, the term "data value" may be used interchangeably with the term "source data value". Similarly, the term UI attribute may be used interchangeably with the term "target attribute". These bindings 226 and 228 allow dynamic properties (ie, target properties) to be set automatically from a data value (ie, source data value), such as from any object's properties. These bindings can be dynamic to automatically update the bound target attribute to reflect changes in the source data value.

In order to provide this automatic update function, the present invention further provides a notification mechanism (eg, shown in FIG. 2 by arrows from notifiers 236 and 240 and notifiers to platform 220). to provide. Each data item 232 and 234 has a corresponding notifier 236 and 240, respectively. The notification mechanism is responsible for informing the system that the source data value has changed and that the data value can be passed to the target attribute (ie, UI attribute).

When bindings 226 and 228 are created, such as through markup, code, and the like, binding engine 224 creates a binding object (eg, binding objects 250 and 252) associated with the binding. . For example, the binding object 252 can represent the binding 228 in the binding engine 224. Each binding object includes several attributes (eg, binding attributes 260-272). Each of these binding attributes 260-272 can be set programmatically. The discussion below describes each of these attributes and FIG. 4 shows example code for activating a binding specifying some of these attributes.

One of the binding attributes (hereafter referred to as path 260 herein) identifies how to place source data values (via the source object). The path 260 can refer to attributes, appendages or indexers in the source object, columns of ActiveX Data Objects (ADOs), XPaths in XML, and the like. Alternatively, the path may refer to a reflection or ADO path.

The other of the binding attributes (hereinafter referred to as bind type 262 herein) defines the types of bindings 226 and 228. In one embodiment, the bind type includes oneWay, twoWay, and oneTime. As shown, binding 226 represents a twoWay binding and binding 228 represents a twoWay binding. One of these binding types is set to default. In one embodiment, the twoWay binding is set to the default binding type.

If bind type 262 is specified as oneWay, it signals binding engine 224 to update the target attribute (eg, UI attribute 210) whenever a change is made to the associated source data value. The oneWay bind type is useful for binding data values to non-editable UI properties such as text color and text background. As will be described below, using the oneWay bind type can avoid the overhead of the twoWay bind type. This reduction in overhead is most notable when hearing changes in UI properties regarding layout content. In the case of these UI attributes, the dynamic attributes of each child of the UI attribute must be heard about the change of the UI attribute. The oneWay bind type can also be useful when changes in UI properties detail the different representations.

If bind type 262 is specified as twoWay, it signals binding engine 224 to update the target attribute for every change that occurs to the source data value and so on. The twoWay binding is particularly useful when binding data to an edit box that needs to communicate any changes made by the user to the source data values. Another scenario of the twoWay binding is when another application takes care of the source data fields and the edit box reflects these changes.

Once the bind type 262 is set to oneTime, it signals the binding engine 224 to initialize the target attribute at one time and then leave it uninitiated even if the associated source data value has changed. The oneTime bind type is useful when some target attribute needs to be initialized with some value from the source field and its data context is not known in advance. Also, the oneTime bind type is useful when used as read-only without changing the source data values. If the source data does not support the attribute notification mechanism (e.g., the IPropertyChange interface) of the present invention, the target attribute specified as oneWay will be updated similarly to the case where oneTime is specified as the bind type.

Another of the binding attributes (hereinafter referred to as update type 264 herein) defines an update type when the bind type 262 is designated as twoWay. Typically, twoWay bindings listen for changes in the target attribute and return those changes as source data values. This process is called update of source. Normally, it is desirable to update each time the target attribute changes. However, in certain situations, updating every key after every type wastes cycles and does not give the user the opportunity to correct typing errors and the like. Update type 264 allows the user to specify when an update should occur. In one embodiment, update type 264 may specify Immediate, OnLostFocus, and Explicit. Specifying Immediate will signal the binding engine to update the source data value after every change to the target attribute. Specifying OnLostFocus will signal the binding engine to update the source data value after the target element loses keyboard focus. An explicit specification will signal the binding engine to update the source data value only when the application explicitly requests an update. Typically, this explicit request is made through a method. This method can be called with any setting of update type 264, but this method is useful when the update type is set to Explicit. An example method is shown below:

Binding.GetBinding (myElement, myProperty) .Update ();

The other of the binding attributes (hereafter referred to as source 266 herein) identifies a source data item for binding. In short, as shown in and described in FIG. 4, source 266 may be set programmatically or in markup. Programmatically, the developer provides an objectref (objectref) to the object that the binding should use as the source data item. In short, as described in detail with respect to FIG. 4, in markup, there are various methods for setting source attributes.

The other of the binding attributes (hereinafter referred to as translator 268 herein) accepts class references. Class references can be specified using <Namespace>. <Class>, <Assembly>. The specified class reference is called by the binding engine 224 to convert the source data into a format accepted by the target attribute. As shown in transform 244 of FIG. 2, the method in the class reference invokes this transform. The class reference may also specify an inverse transform (not shown) that converts the target attribute into a format accepted by the source data value. Transform 244 may provide UI semantics or be an on-demand converter.

The other of the binding attributes (hereinafter referred to as culture 270 herein) defines how the source data values should be processed after / before converting the source data values. Culture 270 operates in conjunction with transformer 268 to allow a developer to specify a rule for converting source data values. For example, a culture can specify a particular format for numbers, dates, and so forth. In one embodiment, culture 270 accepts a value of type CultureInfo. The developer has the option of using the rules specified by the culture 270 when implementing the transformation.

The other of the binding attributes (hereinafter referred to as binddflag 272) provides a mechanism for receiving an event that signals to send data. Because the method for data binding described above is asynchronous, bind flag 272 allows the developer to know when the subject has been updated with a new value. To use this mechanism, bind flag 272 is set to "NotifyOnTransfer". Then register the handler for the event using any conventional method. One exemplary use of this mechanism is as follows:

As the example code above shows, once the OnDataTransfer event is triggered, the developer knows that the dynamic property has been updated. Therefore, the developer can use the target value for further processing.

3 is a logical flow diagram illustrating a binding mechanism in accordance with one embodiment of the present invention. In overview, the binding mechanism performs an action to set the binding (blocks 302-306) and then performs an action (blocks 310-338) on the change of the target attribute or source data value specified in the binding. Processing continues at block 302.

At block 302, a binding object is created based on the arguments specified during creation. In short, each attribute for binding object 252 (ie, attributes 260-272 shown in FIG. 2) may be specified as an argument during generation. Bindings can be created via markup, programmatically, and so on. 4 illustrates example syntax for creating a binding and specifying attributes 260-272. Each generating manner specifies a source data item, a path of a data value of the source data item, a target UI element, and a target dynamic attribute of the UI element. Although not shown in this block diagram, the properties of the binding object may also be dynamically modified during runtime, such as through the use of an application programming interface (API). Processing proceeds to block 306.

At block 304, the binding is activated. In one embodiment, the binding can be activated automatically once the binding engine notifies that there is sufficient environment for the binding, such as that the source object exists, the target element is ready for display, and so on. The binding engine is responsible for recognizing the activation of the binding. Processing continues at block 304.

At block 306, the value of the specified source attribute is found. In one embodiment, reflection is used to find the value. Reflection is a general mechanism that allows the caller to get information about the requested object. This information includes supported objects, public properties, and so on. In another embodiment, when the data item is an aggregate, the binding engine performs a plurality of heuristics that determine whether to use the current record or the data object (the aggregate) itself. The first heuristic is applied when a binding refers to an attribute or indexer. In such a situation, the corresponding attribute or indexer of the aggregate object is used when such an attribute or indexer is present. Alternatively, the current record of the collection is used as a data item. Other heuristics apply when no attribute or indexer is present. In this situation, the aggregate object is used for the target attribute as long as the aggregate object is valid. Otherwise, the current record is used. Before proceeding to block 308, if the binding specifies a transform, the transform is applied to that value (block 307). The application of the transform is described in detail below with respect to block 316. Processing continues at block 308.

At block 308, the value that was found is assigned to the target attribute. In one embodiment, a property engine responsible for maintaining a hierarchy of properties may assign values. In another embodiment, the transformation specified during creation of the binding may be called to convert the value before assigning the value to the target attribute. More specifically, the attribute engine can indicate that an attribute has a new value. Once blocks 302-208 have been performed, the binding engine is ready to update the required target attribute and source data values. In general, the binding mechanism is asynchronous.

Therefore, from block 308, processing continues through the two asynchronous paths. The first path (blocks 310-318) is associated with the update of the target attribute and the second path (blocks 330-338) is associated with the update of the source data value. Each of these paths is described below. First, the path responsible for updating the target attribute is discussed.

At decision block 310, the binding engine determines whether the binding associated with the source data value and the target attribute specified the bind type as oneTime. If the bind type is oneTime, processing for this binding is complete and ends. Those skilled in the art will appreciate that if the bind type is oneTime, the binding engine will not listen for source attribute change events. Therefore, in actual execution, the logic in the binding engine does not necessarily perform the check as shown in block 310. In addition, if the data item does not implement IPropertyChange, processing is complete. However, if the bind type is not oneTime, processing continues at block 312.

At block 312, the binding engine listens for notifications related to the binding. Since databinding does not update the destination directly with the source data value, the present invention implements a notification mechanism. Notification mechanisms, such as attribute change notifications and aggregate view "CurrentChanged" notifications, are known in the art and need not be discussed at length. Several actions cause notifications, such as changing data values, navigating pages, terminating, changing records of interest in a dataset, and so on. Since the present invention triggers an update upon the change of the record of interest in the data collection, the present invention provides a convenient mechanism for further separating the user interface and logic. For example, in accordance with the present invention, the developer only needs to write code in the logic to specify how to change the next record of interest in the data collection. Once the change has occurred, in accordance with the present invention, the binding engine will update the user interface according to the already specified binding. As mentioned above, this separation of user interface and logic provides an application that is more powerful and easier to maintain than when the user interface and logic interact.

The following code is one exemplary implementation of the notification mechanism. Although the example code written below is written in C #, one skilled in the art will appreciate that various languages and syntaxes may be used to implement the notification mechanism. In any such implementation, an interface to be used by each data item is defined. Each data item inherits this interface to implement dynamic updates.

Next, event handlers and their arguments are defined.

Class PropertyChangeEventArgs contains a single read-only property named PropertyName with a string type. PropertyName property contains the name of the property that has changed. Each source data item then implements this interface by calling the PropertyChanged delegate whenever one of its properties changes. The following is an illustrative example of implementing a source object (eg, data item 232) in accordance with an embodiment for a notification mechanism.

As the example code above shows, the 'set' method for the 'foo' attribute determines if the new value is different from the old one. If the values are different, the handler is called. Perform reflection to obtain PropertyInfo. More specifically, once the type of an attribute is obtained through reflection, the binding engine can cache the type of the attribute. As such, reflection is performed only once, but not every time a notification is received for an attribute. In another detailed example, an empty string can be passed in an argument to signal that all bindings to each data value of a data item should be updated. This can happen when the source object is not sure which attributes have changed and each binding is going to be updated. Once the binding engine receives the notification that the data source value has changed, processing continues at decision block 314.

At decision block 314, a determination is made whether the binding associated with the changed source data value specifies a translation for that binding. If the binding does not specify a transform, processing continues at block 318. However, if the binding specifies a transformation, processing continues at block 316.

At block 316, the transformation specified in the binding is performed. In one embodiment, transformer 268 is an object described below:

For the above interface, o represents the source value, dp represents the target dynamic attribute, and c represents the culture used during the conversion. The Transform () method transforms the source value o into an object suitable for assignment to dynamic properties of type dp. The Transform () method is called when passing the binding's source data value to the target property. If the Transform () method returns null, the binding engine is signaled to stop passing data values.

Translators can also be used to control other UI properties such as width, height, font, position coordinates (x, y), and so on, based on the associated source data values specified in the binding. Transformers provide the ability to perform logic on data values to present data in several ways. More specifically, the culture can be applied during the transformation specified in the binding. Processing continues at block 318.

At block 318, the target attribute is updated. In one embodiment, the attribute engine assigns a value to the target attribute. In addition, the target attribute may be marked as having a new value. Processing then proceeds to block 312 to listen for the next attribute change notification associated with the binding. Once the application ends or the binding terminates otherwise, processing ends.

As discussed above, from block 308, processing may continue via the second path. Therefore, from block 308, processing continues at decision block 330. As described above with respect to block 310, the logic in the binding engine may not necessarily perform a check of the bind type during decision block 310, but rather the binding engine may listen for notification when a binding has been created. Since not listening, the process does not flow through the second path. However, for the sake of clarity in describing the flow, a decision block reflecting the bind type is shown. Therefore, at decision block 330, a determination is made whether the bind type is the binding designated as twoWay. As mentioned above, twoWay allows propagation of target property changes to source data values. If the binding does not specify twoWay as the bind type, processing ends. However, if the binding specifies twoWay as the bind type, processing continues at block 332.                 

At block 332, the binding engine will recognize the particular action that triggers the update to the source data value. Once the trigger occurs, processing continues at decision block 334.

At decision block 334, a determination is made whether the binding specifies an inverse transform for that binding. If the binding does not specify an inverse transform, processing continues at block 338. However, if the binding specifies an inverse transformation, processing continues at block 336.

In block 336, an inverse transform is applied to the source attribute. In one embodiment, the inverse transform is an object described below.

In the above interface, o represents the source value, c represents the culture used during conversion, and pinfo represents the PropertyInfo of the target attribute. The InverseTransform () method transforms the source value o into an object suitable for assigning to an attribute of type info. These methods are called when passing the target value of the binding to the source. If the InverserTransform () method returns a null value, the binding engine does not pass a value. Once the InverseTransform is performed, processing continues at block 338.

At block 338, the source attribute is updated according to the update type. As described above, the update type may be immediate, on loss of focus, explicit, or the like. Once the source attribute is updated, processing ends.

4 illustrates some example means for creating a binding. The generating means 400-410 generate the binding through markup. The generating means 410 generates a binding through the code. The example means shown in FIG. 4 is not exhaustive. Other means (syntax) can be used without departing from the scope of the present invention.

The generating means 400 comprises a DataContext name / value pair (hereinafter referred to as DataContext 422) for the element 424 and an Id name / value pair (hereinafter referred to as the Id 420 herein). . Since the generating means 400 includes the DataContext 422, the Id 420 is not necessary. Id 420 is required when it is desirable to refer to an explicit source, such as using the Markup's ElementSource or the code's IdObjectReg. Both of these uses are described below. DataContext 422 is a dynamic attribute defined for an element (eg, element 424). The value associated with DataContext 422 represents a default source data item and is an inheritable attribute. The binding engine uses the DataContext 422 when querying the DataContext 422 and creating a binding of the element 424 and the inheriting element (eg, button element 426). The binding engine also listens for changes in DataContext 422 and thus triggers updates. Therefore, although not a requirement, DataContext 422 provides a convenient mechanism for establishing scope for all attributes bound to generic data items. An inheriting element may have its own DataContext that will take precedence over the DataContext 422 of the parent element. As will be described below with respect to the generating means 402, the binding can override the DataContext 422 by providing a non-null source.

A button element 426 is shown with a target attribute (eg, Button.Text 428). According to the invention, when encountering "Data: Bind", the binding engine knows that a binding is being specified. The accompanying name / value pair sets the binding attributes 260-272 specified in FIG. Those skilled in the art will appreciate that the term "Data: Bind" signaling a binding is any term and any number of terms may be used without departing from the invention. The generating means 400 represents a vast markup format.

The generating means 402 represents a dense markup format. UI properties (eg Button Text) appear in a more compact way. Again, "Data: Bind" is used to signal the binding engine that the binding is binding. In addition, the name / value pairs following Data: Bind corresponding to certain attributes 260-272 have been described above with respect to binding object 250 of FIG. 2. For example, an ElementSource name / value pair (hereinafter referred to as ElementSource 434) corresponds to source 266.

Markup has two methods for setting source attributes: ElementSource and DataSource. If neither of these are used, the default value for the source is null, which signals the binding engine to get the value of the element's DataContext attribute during creation and use that value as the source object.                 

If the generating means (e.g., generating means 402) specifies an ElementSource, the binding engine looks for the element whose ID is specified by the ElementSource attribute. Then the DataContext of that element is used as the source object. Related path names, such as Parent / Parent and Previous / Previous, can be used to specify the data source. When the binding engine encounters / Parent, it looks for the element parent of the current element in terms of the object hierarchy. For example, if the element is a customer order, the / Parent specification can signal the binding engine to find the element corresponding to the customer for the current order. The / Previous specification is useful in nested repeater cases where it is desirable to use a value from an external repeater in the range of an internal repeater. Specifying / Previous signals the binding engine to find the element before the current element under the repeater. The / Previous designation is useful when it is desirable to access the current n items in addition to the current item, such as in a line graph. Inherited / Previous and / Parent can be used in accordance with the present invention.

In other embodiments, the markup may specify a data source. If a datasource is specified, the binding engine receives the resource id of the resource. If the resource exposes a data attribute, the binding engine sets the source of the binding to the object returned by the data attribute of the data source resource. Otherwise, the binding engine will set the source of the binding to the resource object itself.

Those skilled in the art will appreciate that there are a variety of ways in which attributes 260-272 can be expressed using markup languages, and therefore, each of these different attributes can be represented using markup languages. The manner in which this may be done is not described in more detail herein.

The following three generating means 404-410 provide illustrative examples in the type of item to which the present invention can bind. The generating means 404 illustrates the support of attachment and binding to the index. The generating means 404 corresponds with the binding di.a.b [3] .c written in C #, where di is the associated data item. Data items, classes implementing di.a, classes implementing di.ab, and classes implementing di.ab [3] .c all support the notification mechanism of the present invention (eg, IPropertyChange) and their properties. The binding specified using the generating means 404 will cause the binding engine to automatically update the bound attribute (eg, the target attribute) to reflect the change in the source data value, as long as it is notified when this change is made.

The generating means 406 shows the support of the binding to the data aggregate. The binding engine automatically uses the current record of the aggregate at each level, where a, b, and c represent different levels. For example, if di.a has a type IDataCollection, the binding fetches the "b" attribute using the current record of the collection. Therefore, the binding engine automatically updates the values associated with the data collection whenever the current record changes.

The generating means 408 shows the support of the binding to the XML node. A path 260 to the value is provided using an xpath expression, such as " / Customer / Order [@ OrderID = 10] / Amount), shown in FIG. The generating means 410 shows the support of the binding to the ADO data table. In this implementation, the path 260 to the value is provided as the field name for the particular column, such as "OrderID", shown in FIG.

The generating means 410 generates the bindings programmatically. The developer provides an object reference to an object whose binding should be used as a source data item. The program statement shown in the generating means 412 generates a binding that performs the same action as that shown by the generating means 410. The SetBinding method has a number of more complex variations that allow the programmer to specify any of the binding attributes described above. The simple example above uses the button's DataContext as the source object. The following program statement creates a oneWay binding that uses a specific object (known at runtime) as its source.

The following code example illustrates one implementation of controlling user interface attributes for data through the binding mechanism of the present invention. In this example, the data value (eg myInteger) and the UI property (eg TextContent) are activated with a binding. In addition, a transform (eg, MyTransformer) is assigned to this binding.

Therefore, as described, the present invention provides a mechanism for associating source data values with target attributes in such a way that changes in coding of the user interface and logic can be separated. Therefore, the present invention allows developers to easily modify and enhance the user interface without modifying the basic logic of the application.

In the foregoing specification, examples and data provide a complete description of the fabrication and use of the constructs of the invention. Since various embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims below.

Claims (38)

A computer readable medium having computer executable instructions for controlling a user interface attribute in accordance with data, the method comprising: The command is Generating a binding that associates a target attribute with a source data value, and And upon receiving a notification that the source data value is undergoing a change, reflecting the change in the target attribute based on the binding. The method of claim 1, And the target attribute comprises a user interface attribute. The method of claim 1, And applying a transform to the source data value prior to reflecting the change to the target attribute. The method of claim 1, Creating the binding comprises specifying a binding type for the binding. The method of claim 4, wherein The binding type comprises a first binding type that calculates the target attribute that is updated based on the source data when the binding is activated. The method of claim 4, wherein The binding type comprises a second binding type that yields the target attribute that is updated when the source data value undergoes the change. The method of claim 1, Updating the source data value by changing a destination for the destination attribute. The method of claim 7, wherein Updating the source data value is performed asynchronously shortly after the object change. The method of claim 7, wherein Updating the source data value is performed asynchronously when the focus of the target attribute is lost. The method of claim 7, wherein Updating the source data value is performed explicitly by an application. The method of claim 1, Generating the binding is specified using code. The method of claim 1, And wherein said generating said binding is specified using a markup language. The method of claim 1, Creating another binding that associates the target attribute with another source data value. The method of claim 1, And the source data value is associated with a data source. The method of claim 14, The data source is specified via XPath in XML, columns in ADO, and reflection. In a computer system that controls user interface attributes in accordance with data, Processor, and A memory allocated for a plurality of computer-executable instructions loaded into the memory for execution by the processor, The computer executable instructions are Creating a binding that associates a target attribute with a source data value, and When receiving a notification that the source data value is undergoing a change, reflecting the change to the target attribute based on the binding. Computer system. The method of claim 16, And the target attribute comprises a user interface attribute. The method of claim 16, And applying a transform to the source data value prior to reflecting the change to the target attribute. The method of claim 16, Creating the binding comprises specifying a binding type for the binding. The method of claim 19, The binding type comprises a first binding type that calculates the target attribute that is updated based on the source data when the binding is activated. The method of claim 19, The binding type comprises a second binding type that yields the target attribute that is updated when the source data value undergoes the change. The method of claim 16, Updating the source data value by changing a target for the target attribute. The method of claim 22, Updating the source data value is performed asynchronously shortly after the object change. The method of claim 22, Updating the source data value is performed asynchronously when the focus of the target attribute is lost. The method of claim 22, Updating the source data value is performed explicitly by an application. The method of claim 16, Creating the binding is specified using code. The method of claim 16, Creating the binding is specified using a markup language. A computer readable medium having computer executable instructions for controlling user interface attributes in accordance with data, the method comprising: The command is Logic areas for manipulating data values within the application, A user interface area in the application, the user interface area being responsible for displaying user interface attributes, independent of the logic area, and At least one binding specification, wherein the binding specification describes a relationship between the user interface attribute and the data value so that a system level code is notified when the data value undergoes a change so that the system level code is sent to the user interface area. Can instruct to reflect changes in interface properties- Computer-readable medium comprising a. The method of claim 28, And the binding specification is specified by code. The method of claim 28, And the binding specification is specified by a markup language. The method of claim 28, The binding specification identifies a source data item, a path to the data value of the source data item, a target user interface element, and the user interface attribute at the target user interface element. The method of claim 31, wherein The binding specification also identifies a transformation to be applied to the data value prior to reflecting the change in the user interface attribute. The method of claim 31, wherein The binding specification also identifies a data type for the binding. The method of claim 33, wherein The binding type comprises a first binding type that calculates the user interface attribute that is updated based on the data value when the binding is activated. The method of claim 33, wherein The binding type comprises a second binding type that yields the user interface attribute that is updated when the data value undergoes the change. The method of claim 31, wherein The binding specification also specifies that the data value is updated when the user interface attribute undergoes a UI change. The method of claim 36, And the data value is updated asynchronously shortly after the UI change. The method of claim 36, The data value is updated asynchronously when the focus of the user interface attribute is lost.

Images