InfoPath, custom WCF Service, Word and Open XML SDK (outline)

This upcoming series of articles promise to be far more exciting than the title.

Scenario

How do you use an InfoPath form document to populate a word document with content controls. 

Steps:

1. Building a Word document template with Content Control place holders
2. Use Content Control toolkit to bind values to place holders in the template to an embedded custom XML (hey, isn't an InfoPath document an XML file?)
3. Creating a WCF service to take a Word template document, and replace the custom XML, by the power of Open XML SDK (2.0, of course).
4. Invoking the WCF service from within an InfoPath document to generate a word template version of itself!
5. Finally, a bit of discussion on where Word Automation services fits in the bigger picture, as well as thoughts on best practices.

Drop a comment below if you have any specific questions relating to these steps.  Specifically, if you can think of a far better title for this series.

Otherwise, stay tuned!  :-)

InfoPath - disabling backspace key in browser form

How to disable the backspace key using Javascript/jQuery for an InfoPath browser form in SharePoint 2010.

The problem

One really troubling problem with almost all web solutions is how the Backspace key works.  By default, it tells your browser to go back to the previous page in history.

If you are just browsing around on your Intranet, this is probably not a big deal - firstly, you wouldn't be pressing backspace unless you actually wanted to go back.  Secondly, if you did indeed made a mistake and pressed the backspace key, you'd just undo that action by clicking the forward button, or navigate to another link.  No problem.

When you are filling in a form on the browser though, such as through InfoPath, suddenly the backspace key is a big deal.  You users may be using the backspace key to delete text that they are in the middle of entering.  And if they didn't have a textbox focused, the backspace key is sent to the browser form, and suddenly you have a problem.  The form disappeared, and you have lost information.

InfoPath is quite smart - it remembers which view you are supposed to be on, and when you navigate to an outdated browser historical view of the form - Form Server will automatically redirect you forward to show you the correct form you are supposed to be viewing.  This is good, at least in the navigation sense.  So the only remaining problem is the lost data - your user may have had a whole page filled out and this mistake has just cleared their form.  Not good.

Enter Javascript

So, the plan is simple:

1. Inject javascript to the existing browser form
2. Listen to keydown event for a backspace key (keycode 8)
3. Eat the event and stop it from propagation, so the browser don't see it

Using jQuery, you'll need this simple function.

function document_keydown(e) {
    if (e.keyCode == 8 && e.target.tagName != "INPUT") {

        // letting us know we've ate a backspace key
        SP.UI.Notify.addNotification('Ate a backspace key, hew!', false);

        // cancel backspace navigation
        e.preventDefault();
        e.stopImmediatePropagation();
        return false;
    }
};

$(document).keydown(document_keydown);

Injecting Javascript in modal dialog

If you are using SharePoint 2010's modal dialog to show InfoPath in a modal popup, it's slightly trickier.

// grab a reference to the modal window object in SharePoint
var w = SP.UI.ModalDialog.showModalDialog(options);

if (w) {
    // get the modal window's iFrame element
    var f = w.get_frameElement();

    // watch frame's readyState change - when page load is complete, re-attach keydown event
    // on the new document       
    f.onreadystatechange = function(e) {
        if (f.readyState == 'complete') {
            var fwin = f.contentWindow || f.contentDocument;
            $(fwin.document).keydown(document_keydown);
        }
    };
}

Result

nom-nom-nom backspace keys.

Note, because the Javascript catches the keypress event at the document level.  If your user still has focus on the input (textbox) level, the event will not be stopped - so your user still will be able to backspace when they are using a textbox.

InfoPath - creating sequential filenames without an extra column

Avid InfoPath form creators will no doubt know the trick to create sequential numbers for use in filenames.  The steps typically includes:

1. Create a field FileName, create another field SeqNo.
2. Publish the form to SharePoint Form library, and promote the column for SeqNo
3. Create a view, use REST data connection or use owssrv.dll to get data from this Form library, in particular we want to know the SeqNo
4. Prior to save, check that the FileName is not blank, query the data connection to find the latest SeqNo from the forms library.  Using max()
5. Add one to this number, store it in SeqNo
6. Create FileName by concatenating some prefix with SeqNo:  MyFile-004
7. Submit through a data connection back to the Form library with the FileName

This blog post is NOT about using a second column

We will work out the next number completely without promoting any fields.

WHY, you may ask.  Well, because it's FUN!

And we get to play with a modified double-eval trick as a bonus!

Set up

• Create a basic form, create a field filename
• Publish to SharePoint Form library

Secondary data source for querying existing filenames

Create a SharePoint connection to the Form library.

Here I'm creating a SharePoint List data connection.  The old trick with owssrv.dll will work as well.

Secondary data source for submit (to save forms)

Another SharePoint connection to the Form library, this one is for submit.  Allow overwrite.  Also, use the filename field for saving.

Save button

Create a save button.  When the user clicks save, we're going to create a new filename with a sequential number, then call the submit data connection.

Our secondary data looks like this:

I drop this onto the form to show what is the data in this data connection.

What we want to do, is to take the names, strip out all the non-numeric characters, and then perform a max() operation to find the largest number.

Stripping characters with TRANSLATE

InfoPath has a useful function translate("abc", "ABC") it replaces the first set of characters with the second set.  If your second set is empty, like this: translate("abc", "") you can essentially perform a character removal.

And now, I can use my translate function like this:

Run the form in preview: we are now left with just the the numbers in the filename.  Good.

Double-eval

Back to our list of existing form names. 

The double-eval trick essentially gives us a way to do a for-each parse through a repeating section in InfoPath.

The basic form this is:

The inner-eval, runs "." (current), and the outer-eval, runs ".." (parent).   Combined, this gives us a concatenated string of all the Title

Combine both the translate strip, and the double-eval, we get:

Preview:

Finally, replace the outer-eval with a max function, and prefix a 0 (for filenames that don't have numbers).

max(eval(Title, 'concat("0", translate(., "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz -+,_!.", ""))'))

Preview result:

So my filename function is this:

concat("form-", max(eval(Title, 'concat("0", translate(., "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz -+,_!.", ""))')) + 1 )

Here's the form running in Form Server

Download

• https://static1.squarespace.com/static/5527bff2e4b0b430660b0d10/5527c30de4b030eeeef09715/5527c30fe4b030eeeef09eca/1329912112443/SequentialFileForm.xsn

InfoPath how to copy a repeating section using rules

For years, we all thought this was impossible.  You had to use code.  I somehow woke up with an idea on how to do this, and set about testing and to my surprise, found a solution.  Here it is!

The form set up

• Two repeating sections, Foo's and Bar's
• One additional integer field i to control which row to copy

Put the elements on the form:

The copy rule

Create a rule on the integer field i

1. We will use the normal action, then tweak it. 
   Give this rule the name "Copy"
   Start by defining a set field value rule.
   
   
2. Set /my:myFields/my:Foos/my:Foo/my:F1 to /my:myFields/my:Bars/my:Bar/my:B1
   
   
   There are a few issues so far with the default Set Field Value action related to a repeating section.
• For the Field (target), it will set ALL the matching nodes.
• For the Value, it will get the First matching node.
  
3. Let's fix the second value - we can do this in InfoPath designer.
   
   
   The expression is:
   ../my:Bars/my:Bar[number(../../my:i)]/my:B1
   
   This expression lets us copy a different row.
   
   
   
   So we can now copy value from any row - depending on what the number i is.
   
4. To fix the Field Target is a bit more difficult.  InfoPath designer doesn't give us a way to modify the XPath of the field.
   
   
5. Save the form.  We're about to do unsupported stuff. 
6. Publish the form to Source Files. 
   
   
   I publish to C:\Temp\CopyForm\
   
7. Close InfoPath designer.  Open the file C:\Temp\CopyForm\manifest.xsf file using NotePad or your favourite XML editor.
   
8. The "Copy" rule is hiding in this XML file, it looks like this:
   

<xsf:rule caption="Copy">
    <xsf:assignmentAction targetField="../my:Foos/my:Foo/my:F1" expression="../my:Bars/my:Bar[number(../../my:i)]/my:B1"></xsf:assignmentAction>
</xsf:rule>

9. Change it to:
   
<xsf:rule caption="Copy">
<xsf:assignmentAction targetField="../my:Foos/my:Foo[number(../../my:i)]/my:F1" expression="../my:Bars/my:Bar[number(../../my:i)]/my:B1"></xsf:assignmentAction>
</xsf:rule>
10. Save, and close Notepad.  Re-open manifest.xsf file using InfoPath Designer
    
11. Let's check our rule.
    
    
12. Are you thinking what I'm thinking?  We're nearly there.

The loop

1. This rule is set on the number i, and runs once whenever the number i changes.
   
2. Lets set it up to increment.
   
   
3. Add a condition to stop incrementing when we've run out of rows
   
   
   
   
4. And to start the whole thing, remember we have a button.
   
   
   
   To start the process, set i to 1.  XML index starts from 1 to n.  Does not start at 0.
   

Result - InfoPath Filler

Starting...

Press "Copy"

Result - Form Server:

Starting Browser Form

Copy.

Note - InfoPath "Infinite Loop" limitation:

InfoPath is hard coded to only execute 16 rules before throwing the "Infinite Loop" error.



An error occurred in the form's rules or code. The number of rule actions or the number of calls to the OnAfterChange event for a single update in the data exceeded the maximum limit.

The rules or code may be causing an infinite loop. To prevent this, ensure that the rule action or event handler does not update the data which causes the same rule action or event handler to execute.

There is no solution for hard coded 16 rules.  So your i can not go over 16.

Download

• https://static1.squarespace.com/static/5527bff2e4b0b430660b0d10/5527c30de4b030eeeef09715/5527c30ee4b030eeeef09cf0/1328417804074/CopyForm.xsn

InfoPath - LoadDocumentAndPlayEventLog NullReferenceException

Error:

LoadDocumentAndPlayEventLog failed with unhandled exception System.NullReferenceException: Object reference not set to an instance of an object.     at Microsoft.Office.InfoPath.Server.Converter.DetectUnsupportedNamespaces.VerifyNamespace

This is a very uncommon bug.  Essentially, you are using custom code in InfoPath, and you are using code that doesn't have a namespace.  Say a helper function that you've included in your code.

When InfoPath Forms Services attempt to validate your form, it finds that your form template contains reference to code that doesn't have a namespace!

The fix is simple, create a namespace for the helper class, or move the helper class under the namespace of the form's namespace.