Custom Control support in InfoPath (Part I - Simple Binding)
Over the last year and a half, the InfoPath team has been working on the SP1 release. If anyone's seen the list of features, you'll notice that there are new features with a service pack release. The feature which I've worked on mostly was the custom control support. Basically allowing developers to create and use ActiveX controls within InfoPath. I have a post here: http://blogs.msdn.com/infopath/archive/2004/04/09/110504.aspx but I'll go over the individual binding types seperately because they get a little confusing. What is binding? If you're familiar with InfoPath, you'll notice that behind the scenes, InfoPath stores everything in xml. Each control is associated with some part of the xml. “Binding“ is the term that we use to refer to the connection between the xml and the control.
The first one we'll go over today is the most basic type of binding: Simple Binding.
As the name suggests, it's very simple. ActiveX controls which are set to simple binding will bind to basic data types like strings, numbers, dates, etc... This type of binding is very similar to the rest of the InfoPath controls. For example, textboxes are controls that have simple binding to a string node (by default, but you can change that). Date controls are usually bound to date types. With this type of binding, InfoPath developers can write custom controls and have it save simple types of data into your xml. One example would be a calculator (like the popup ones in MS money). This would provide an in-doc calculator and it could save the number in the xml after the user has calculated whatever number was needed. So simple binding is ideal if you have a single piece of data. If you have multiple pieces of data, you should look into the other bindings.
Sometimes people are tempted to exclusively use this type of binding and avoid the others because they're unfamiliar with the others. We'll go over those later, but here are things to avoid when using simple binding.
Don't try to stuff multiple values into a simple binding. If you have a list of numbers, lets say like stock quotes, you wouldn't want to use simple binding. Yes you could just delimit them with a pipe ( | ) or comma ( , ). It will work, but the whole point of xml is to have structured storage of data. Also, if you have a large amount of information, you could mime or base64 encode everything and stick it in a string. This will also work, but it will make it very hard for other apps to read this xml file. For those two scenarios, the other types of bindings where created.
Custom Control support in InfoPath (Part II - Stream Binding)
Continuing (from Part I) on, we will discuss the second type of binding available to ActiveX controls within InfoPath. This one is called “Stream Binding” (which corresponds to the “Field element with custom data type“ in the drop down of the custom control wizard).
Remember in the first binding type(simple) I mentioned that it's not good for storing multiple values. Stream binding is a type where multiple values can be store. But it does oh so much more. What do we mean by “stream”? Basically, stream binding allows ActiveX controls to save arbitrary xml into your InfoPath form. Yes arbitrary. But wait, you say. My form has a schema. Yes it does, so stream binding will ask for a different namespace which your control can write whatever arbitrary xml into without making your InfoPath xml file invalid because it's in a different namespace than your InfoPath form schema. To give an example of how that happens, there is actually a built in control that does something similar to stream binding. The rich-text box control that comes in the standard controls just saves rich-text via xhtml. The xhtml schema isn't embedded into a form which has a rich-text box, rather, it writes out all the xhtml into another namespace. The rich-text node in the schema just specifies that the xml in that node be part of the http://www.w3.org/1999/xhtml schema.
This type of binding is good for cases when you want to store multiple values and not have to require InfoPath form developers to create the appropriate nodes in the data source. When a stream bound ActiveX control is added into the form, it will just create one node which will point to a different namespace. The benefit of this is that form developers will not have to create a particular structure if they want to use this control. Stream binding is an excellent choice if an ActiveX control already outputs xml.
Now what happens if you want your ActiveX control to interact with multiple nodes within your form? This obviously won't work with stream binding because stream binding will write xml in a different namespace. This is where the third type of binding comes in.... stay tuned...
Custom Control support in InfoPath (Part III - Node Binding)
Continuing (from Part II) on, we will discuss the third type of binding available to ActiveX controls within InfoPath. This one is called “Node Binding” (which corresponds to the “Field or Group (any data type)“ in the drop down of the custom control wizard).
What happens if you want your ActiveX control to interact with data that other parts of your form will interact with? For example, you want your ActiveX control to get and set data which a repeating table elsewhere also sets and gets from. Stream binding writes to a seperate namespace, so no part of the InfoPath solution will be able to interact with that data. Node binding in the solution for this. Node binding, as the name indicates, allows the ActiveX control to connect directly to the DOM. The ActiveX is passed in an IXMLDOMNode pointer and anything done by the ActiveX control gets reflected in the InfoPath form DOM. So this type of binding allows you to bind to any part of the DOM whether it be a leaf node, the root node, or anything in between.
As an example, let's say that you had a repeating table which has different values which you would like to graph. With a graphing ActiveX control, you could bind it to the same node as the repeating table. Then the chart control could pull the data and create a graph appropriately. Any changes to the repeating table would then get reflected in the graphs.
The only down side to this type of binding is that you will most likely have to write these type of controls yourself. With simple binding and stream binding, you may be able to find controls you can use out of the box, but controls that have a property for an IXMLDOMNode are very few.
This ends the three part series on the types of binding for custom controls in InfoPath. I hope this has been helpful. Please use the comment thing below if you have any questions or need any clarifications.
转载：http://blogs.msdn.com/ajma/archive/2004/07/09/178857.aspx