InfoPath - an example of using an XML file for special characters

This is an old trick relating to inserting special characters (such as carriage returns) and tricking InfoPath to stop removing them! 

http://blogs.msdn.com/b/infopath/archive/2005/03/04/385577.aspx

I've decided to take some screenshots to show what you should be expecting when you apply this technique.

The XML file

The Data Connection

A formula to use it

The advanced Xpath is:

concat("my", xdXDocument:GetDOM("characters")/lookups/characters/@crlf, "hello", xdXDocument:GetDOM("characters")/lookups/characters/@crlf, "world")

Result - Rich Client

Result - Web Browser Form

The HTML generated in the browser form is:

<TEXTAREA ...>my
hello
world</TEXTAREA>

Notice it has the correct carriage returns creating the new lines.

The example XSN file if you want to download it and have some fun

https://static1.squarespace.com/static/5527bff2e4b0b430660b0d10/5527c30de4b030eeeef09715/5527c30fe4b030eeeef0a0ca/1318394572343/crlf.xsn

InfoPath - abusing a secondary datasource as temporary variable

This is an InfoPath technique that I've recently started using, and is pretty awesome.

Problem:

• InfoPath is great with rules and fields, but modifying the field means that your form has now changed.  In code behind we have formstate variables, but they are not visible by InfoPath rules.
• We may want to change these fields in later versions of the template.
• If only we can have temporary variables to use in InfoPath

Solution in one sentence:

• Create a secondary datasource, use abuse it to hold variables that you don't want to save to your main form

Real Example

How to detect if your form has been changed by the user since it was opened.  This is a tweaked version of Alec Pojidaev's How to check if your InfoPath form is “dirty”? (Tracking changes) using secondary temporary variables.

Steps

1. Create a separate secondary datasource
   
   
2. Add the XML file as a secondary datasource
   
   
3. Now we have a secondary data source that we can use
   
   
4. Use that datasource to keep all the "UI" logic.  Such as:
• "a checkbox to confirm whether I want to save and close, or just close"
• A rich text field to show a message that I display on a separate message View
• Various validation or toggle Booleans to control the UI
5. Because the secondary datasource is not saved back to the main datasource, changes to the secondary datasource tree can be considered "discarded", effectively giving us "temporary variables" that rules can use.
   
6. Create the form rules
   
   
   
7. Set the field "Form" on the secondary data source to that of the current main datasource
   
   
8. To test if the current form, at a later point in time, is the same as the form when it was opened
   
   

Demo

1. On open, is the form the same as when we opened?
   
   
2. After some changes
   
   
3. Delete our changes - "true" again
   

How to use it

1. When a form is opened, use rules (or code) to set the default values in the secondary datasource
2. Through the lifetime of the form you can set the values to whatever you want, and use it in conditions
3. When the form closes it doesn't get saved

Benefits

1. You can track UI logic without actually modifying the main form
2. You can then use the string(.) trick to save the current form on form-load, then use that value to compare with the form at a later date to see if the form had been changed by the user
3. Some values, like "current user displayname" can be stored temporarily and is perfect for this
4. If you didn't like a temporary variable, just remove them or rename them.  Because they are not saved to the main data source, you don't have to worry about breaking existing or future forms.

InfoPath - how to do case-insensitive text compare

Because XML is case sensitive, in InfoPath you have the problem that field may not be equal to another field during text comparison due to their case.

One way that people have been relying on is the TRANSLATE function, which requires you to write really crazy code like this:

translate( /my:fieldx, "ABCDEFGHIJKLMNOPQRSTUVWXYZ", "abcdefghijklmnopqrstuvwxyz" );

Except you usually need to do this for both sides of the equation.

A less well known function is actually the Microsoft extension msxsl:string-compare

http://msdn.microsoft.com/en-us/library/ms256114.aspx

Here you can use this to compare the current user's name.

msxsl:string-compare(my:a_user, xdUser:get-UserName(), "", "i") = 0

The string-compare function will return 0 based on whether the strings are identical.  The 3^rd optional argument is language, using an empty string will default to system.  The 4^th optional argument is case-insensitive.

The msxsl:string-compare is supported in both InfoPath 2007, 2010 and works in browser forms.

Check it out! :-)

InfoPath – designing verification form

I’m quite a fan of having a validation summary block in InfoPath, similar to how one would have validation in ASP.NET.

To start, we can create sections directly from our fields.

You can right-click drag the fields directly into the designer and select “Section”.  This will create empty sections that are bound to the fields directly.

Put text labels within the sections with a friendly message for each field.  I also made the default background light red.

Create validation rules to ensure the field isn’t blank.  Hide the control when they are valid.

The end result is a pretty view for validation.  When the textbox is blank, the validation warning appears.

10 InfoPath tips for SharePoint developers

Here are 10 nice tips designed for someone that's familiar with SharePoint, but may be new to InfoPath. 

Having brooded over the idea for a while, I decided to quickly write this down, and if there are any questions I can expand some of these key points.

1. Use InfoPath Designer 2010 to author your forms, even for 2007 forms. The UI is better, design checker gives you more information, and the rules editor supports copy/copy all and paste.
   Note: design checker gives you a lot of warnings and sometimes... they can be ignored.  Which ones are safe and which aren't... is as far as I know, a personal experience thing, think of it as VS.NET warnings.
2. Design your main context fields first, and then try your best not to change existing fields (add new fields are OK).  Removing or renaming fields often break existing forms that had already been filled out.
3. Decide upfront whether this is a rich form or a browser form, and set the compatibility level appropriately.  Use the design checker. 
   If you are planning to create hybrid forms that works on both - there's a form option that will allow your code behind to use the Rich Form API but still check the form for Browser Form compatibility.  In this case, always check in your code whether the form is running in the browser before you call those APIs, otherwise you will get UnsupportedExceptions.
4. If you need to promote InfoPath fields to SharePoint so they appear as columns (and can be used in workflows), you should always use site columns.  You might want to consider always using Content Type as well. 
   It may be tempting to use publish to list - but this creates list fields that are now very hard to manage, and when you realize down the road that you should have used content types, you now have to fix existing list columns and move their data to the site columns.  This always happens. 
5. Brush up on your XPath skills well.  InfoPath renders every view via a XSLT transform and the output is actually a HTML page (either for rich form or web forms).  You need to use XPath when you want to start defining rules that are relative to the current field.  Why use rules when you can use code behind?  See next point.
6. Code behind are powerful, and may look much simpler to a developer, but has deployment considerations.  In 2010, code behind can run either in a farm solution, or via the sandbox user code service.  However, code in the sandbox service sometimes may not run when the service is "busy".  Your best bet is either: deploy code through central administration - if you have access, but then you trip up tip #4 if you haven't been using site columns, or don't use code behind and write your logic using only rules.  You can find detailed InfoPath documentation for developers on MSDN (it may not look like much, but you have functions like get-SharePointServerRootUrl that are just gems hiding)
   Plus, trust me you feel awesome when you can write complex logic using declarative XPath and no C# code. It's like saying yes I could cheat and just use C#, or I can be godlike and do it in XPath.
7. Copying pictures increases your resource size.  The best way for a repeated picture is to include it as a resource, then use a picture button and set the image to your included resource.  Unfortunately you can't set the image of a picture control.
8. Export form as Source files, and work with the manifest.xsf.  While I'm pretty certain it is unsupported to tweak the view.xsl files manually by hand, at least you can now put all the component files within a source control and check what has changed using a simple text difference tool.
9. Learn how to call webservice with Rules.  InfoPath is pretty dumb beyond what's within the form.  Webservices gives you lots of capabilities but only if you know how to call them.  E.g. how to interact with SharePoint users.
10. Don't use the "can't be blank" option, always create validation rules.  When any validation rules fail, it puts the form into an invalid state and prevents any submit action.  If you have them all defined as validation rules - you can add an additional condition that allows saving E.g. if ForceSave = "0" and "MyField" is empty
    This gives you control over what happens when the user is trying to save, and allow you to disable the checking when you need to.

Leave a comment if you feel this was helpful, or you want more explanation for any of the points.  Thanks for reading.