One stumbling block for developers coming up to speed on InfoPath is that the SDK documentation leads you to the edge of the XML cliff and then goes mysteriously quiet. For web developers who have programmed applications with the MSXML SDK for manipulating XML this isn’t a problem – they brought their parachute with them and happily jump off. For others, this can be a little intimidating.
Here’s a good way to get started manipulating the XML DOM directly – let’s add “Move Up” / “Move Down” buttons to a Repeating Table so you can re-order the items.
First off, let’s build the view:
At this point, you’re thinking “5 and 6???”
(Sneaky, huh? Glyphs from this font are used by Windows to render all sorts of UI elements like the Minimize/Maximize Window buttons. This is a handy way to avoid having to use images for simple things like arrows.)
Now that we have it looking pretty, let’s add the event handlers for the buttons. We’ll build on the logic from this blog entry to figure out which instance of the buttons was clicked.
' Write your code here
Dim oItem, oParent, oPrevious
Set oItem = eventObj.Source
Set oParent = oItem.parentNode
Set oPrevious = oItem.previousSibling
If Not ( oPrevious Is Nothing ) Then
oParent.insertBefore oItem, oPrevious
The logic here is straightforward:
Dim oItem, oParent, oNext
Set oItem = eventObj.Source
Set oParent = oItem.parentNode
Set oNext = oItem.nextSibling
If Not ( oNext Is Nothing ) Then
oParent.insertBefore oNext, oItem
The logic here is similar:
Almost done – let’s just use a little Conditional Formatting to disable the buttons when the item is the first or last in the list:
Now try it out.
As an aside, this was the author’s first foray into VBScript. Although I cut my teeth in Applesoft BASIC I’ve done most of my programming in C-style languages (C, C++, C#, Perl, Java). Did I do anything silly?
Q: How do I get the red asterisk to show on a Rich Text Box? There isn’t a checkbox for “Cannot be blank” on this type of control!
A: Easy - add a declarative data validation rule for the condition where the field bound to the Rich Text Box “is blank”. To get started, display the control’s properties dialog box and then click Data Validation.
So now you’re wondering – why isn’t there a simple checkbox for that?
Behind the scenes, the “cannot be blank” checkbox actually maps to a change in the schema, rather than a declarative validation rule. For strings we add a length restriction, but for other types it sets nillable="true" (can be blank) or nillable="false" (cannot be blank).
This explains why the checkbox is enabled when using a schema you’re creating in InfoPath and disabled when using a fixed schema from an external source. Since the schema we use for rich text (XHTML) nodes is a complex type the nillable approach doesn’t apply.
So why does a declarative validation rule cause a red star to appear? When the form is running, the validation display semantics don’t distinguish between schema validation, declarative validation, and even code validation if you use an OnValidate event handler and/or add to the Errors collection. The logic for the validation display is:
if( node fails validation )
if( string value of node is blank )
show red star
show red border
When adding a web service data connection to an InfoPath 2003 form template, there is a bug that will cause InfoPath 2003 to disappear if the web service’s WSDL contains a particular recursive schema construct. The following snippet of XSD illustrates the issue:
<xs:element name="Branch1" minOccurs="0">
<xs:element ref="ns:RecursiveRoot " maxOccurs="unbounded" />
<xs:element name="Branch2" minOccurs="0">
<xs:element ref="ns:RecursiveRoot" maxOccurs="unbounded" />
This XSD contains a recursive structure in which there is more than 1 path of recursion and the recursive root is not marked as an optional element in the XSD when referenced. InfoPath 2003 will work with the WSDL containing this XSD as expected if both references to RecursiveRoot were optional as illustrated in the following modified XSD (changes in red).
<xs:element ref="ns:RecursiveRoot " maxOccurs="unbounded" minOccurs="0"/>
<xs:element ref="ns:RecursiveRoot" maxOccurs="unbounded" minOccurs="0"/>
If you are having issues with a web service that you own, one work around to this issue with InfoPath 2003 is to modify the WSDL for your web service as shown above. In the case that this is not an acceptable work around, or you do not own the web service, the following steps will help you work around the problem:
1. Download the WSDL file for the web service to your local machine
2. Modify the XSD in the WSDL as shown above
3. Add a Data Connection to the local version of the WSDL file
If you are setting up a submit or receive/submit web service connection then the following steps are required as well to ensure that the data InfoPath submits to the web service adheres to the original schema:
4. File --> Extract Form Files to save your form template in an uncompressed format
5. Remove the modifications made to the WSDL XSD in the copy of the XSD that was added to the form template
If you modify the data connection or add another data connection to this local WSDL file for a submit web service then steps #4-#5 will have to applied again. If you expect other users to modify the design of this form template then the local version of the WSDL should be stored in a shared location that all designers have access to.
This issue has been reported to the InfoPath team as occurring in the ItemLookup method of the web services that Amazon exposes (http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl). In the case of this method, the modification that is necessary to avoid the InfoPath 2003 bug (step #2) is the following: 1. Find the BrowseNode element that contains references to other BrowseNode elements 2. Add minOccurs=”0” to the BrowseNode references (these occur under the “Children” element and the “Ancestors” element) Since ItemLookup is a receive only method, there is no need to modify the form template files by hand (steps #4 and #5).
This issue has been reported to the InfoPath team as occurring in the ItemLookup method of the web services that Amazon exposes (http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl). In the case of this method, the modification that is necessary to avoid the InfoPath 2003 bug (step #2) is the following:
1. Find the BrowseNode element that contains references to other BrowseNode elements
2. Add minOccurs=”0” to the BrowseNode references (these occur under the “Children” element and the “Ancestors” element)
Since ItemLookup is a receive only method, there is no need to modify the form template files by hand (steps #4 and #5).
Rushi Desai, a developer on SQL Server Engine, has posted some blog entries on integrating InfoPath with SQL Server 2005:
Integrating InfoPath with SQL Server 2005
Download and try the InfoPathBroker sample
The first one explains the architecture for interfacing InfoPath with the SQL Server 2005 Service Broker feature. The second has the samples and instructions on how to set up the environment.
Check 'em out!