Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

  • Microsoft InfoPath 2010

    Conditional Presence versus Conditional Visibility


    InfoPath supports a feature called Conditional Formatting which allows among other things to show or hide sections of the form based on some condition.


    However, the underlying XML data still stays there even though it is not visible in the view. What if one wants to remove the XML data altogether? It is easy to achieve this by writing a little bit of code.


    First of all, a trick: an optional leaf field can be wrapped in an Optional Section without adding any additional nodes in the Data Source. Suppose that your data source looks like that:





    Instead of dragging field1 into the view (which will produce a Text Box, assuming its datatype is a string), right-click on it, select More… and pick Optional Section with Controls.


    Now the Text Box is wrapped in an Optional Section and you can remove or insert it as desired.


    At this time, suppose that you want field1 appear conditionally based on a state of a Check Box bound to some node (let’s call it field2). Attach an “OnAfterChange” event to it with the following code:


    function msoxd_my_field2::OnAfterChange(eventObj)


          if (eventObj.IsUndoRedo || eventObj.Operation != "Insert")





          if (eventObj.NewValue == "true")


                XDocument.View.ExecuteAction("xOptional::insert", "field1_1");





                XDocument.View.ExecuteAction("xOptional::remove", "field1_1");




    Here, we use the xOptional::insert command to insert field1 (and hence the Optional Section) when the Check Box is checked, and xOptional::remove to remove it when the Check Box is unchecked.


    A few comments on the code above:

    • The “field1_1” string is the xmlToEdit name associated with the section. To find out what this name is for your section, look at the “Advanced” tab of the Optional Section properties.
    •  When executing actions, InfoPath is using the current XML context to determine how to perform the action. Clicking on the checkbox moves the XML context to field2 in our example. While InfoPath can still handle the insertion properly, it cannot figure out what section to delete. In order for xOptional::remove to succeed, we use SelectNodes() method on the view to set the xml context to the section we are trying to remove.
    • Finally, to prevent the user from inserting or deleting the Optional Section by other means than using the Check Box, bring up the properties of the Optional Section, click “Customize Commands” and uncheck everything under “Insert” and “Remove” actions. Also uncheck the “Show insert button and hint text”.

    P.S. The conditional presence technique is especially useful in scenarios where the schema contains optional elements that are not allowed to be blank (which could be a desirable design in some scenarios where the XML-consuming backend cannot handle xsi:nils).


    P.P.S. The technique of calling View.SelectNodes() can solve the ExecuteAction() focus/context problem. The ExecuteAction() documentation states that sometimes calling ExecuteAction() from button’s onClick can fail. Calling View.SelectNodes() from onClick shold remedy to this problem.

  • Microsoft InfoPath 2010

    InfoPath SP1 Released - how to install on systems with InfoPath SP1 Preview


    You can now download and install the official InfoPath SP1.  It is part of the Office 2003 SP1 download.

    More details: .  English SP1 download is here.

    Please pay special attention to the following if you have installed the InfoPath 2003 SP1 Preview:

    InfoPath 2003 SP1 Preview and Office 2003 SP1

    If you previously installed the InfoPath 2003 SP1 Preview, you should uninstall the InfoPath 2003 SP1 Preview prior to installing Office 2003 SP1. You will need your original InfoPath 2003 product CD to upgrade to the final version of InfoPath 2003 SP1. For more information, see the Microsoft Knowledge Base article (873040): Information to consider before you apply Office 2003 Service Pack 1 to a computer that has the InfoPath 2003 Service Pack 1 Preview installed.

  • Microsoft InfoPath 2010

    Recent InfoPath focused posts by David Fries


    David Fries recently posted several interesting topics specific to InfoPath:

    David also has an InfoPath Specific RSS category feed.

  • Microsoft InfoPath 2010

    Introducing Microsoft® Office InfoPath™ 2003


    Microsoft Learning and Roger Jennings have a new book out through Microsoft Press - Introducing Microsoft® Office InfoPath™ 2003. This book covers InfoPath from top to bottom including the SP-1 feature enhancements and developing InfoPath solutions using managed code.

    From the book's description:
    "Learn how to integrate forms with other Microsoft products such as Microsoft SQL Server and Access databases, Windows SharePoint Services, and XML Web services. This book also provides an overview of the technologies used to build an InfoPath forms solution using Visual Basic .NET managed code and the InfoPath Document Object Model (DOM)."

    You can find a little more information, including how to order, at


  • Microsoft InfoPath 2010

    Recursive Controls support in InfoPath 2003 SP1


    The SP1 release of InfoPath 2003 supports recursive controls such as Repeating Recursive Section and Optional Recursive Section. Based on the schema of the solution, these controls are automatically suggested when dragging nodes from the Data Source task pane. This article talks about different types of recursion that are supported within InfoPath.

    Direct Recursion:

    This is the case when the node is recurring directly under itself. For example, if you are creating an organization chart, you might have a schema that has the following structure:





    Every employee has EmployeeData associated with him and can have 0 or more employees working for him. Note that the * stands for repeating 0 or more times. If you select the top level Employee node in the Data Source task pane, InfoPath would suggest a Repeating Recursive Section in this case with the recursive instance showing up directly under its parent.

    Picture of design mode for the direct recursion structure

    Indirect Recursion:

    This is the case when the node is recurring as a child of another node within itself. For the above organization chart, you may choose to abstract the fact that Employee is a manager or not by introducing an Optional node Manager. In this case the structure is as follows:








    In this case, when you drag top level Employee node, InfoPath will create a Repeating Recursive Section that has the recursive instance within an Optional Section that corresponds to Manager node.

    Picture of design mode of the indirect recursion structure

    Potential Recursion:

    This is the case when the node is recurring under as one of the choices under itself. Again taking the above organization chart example, we may choose to not include EmployeeData for managers since it is covered under ManagerData. So now we could have the following structure:








    Now we have an employee who can either be a manager or not. In this case, when you drag top level Employee node, InfoPath will create a Repeating Recursive Section that has the recursive instance within a Choice Section.

    Picture of design mode of the potential recursion structure

    In summary, you have seen how InfoPath supports various types of recursion in its SP1 release. These three examples were just to illustrate the broad categories of recursion but you can go beyond these and try various other combinations based on your needs.

  • Microsoft InfoPath 2010

    Use patterns (e.g., digits or quotes) to validate data in InfoPath


    Example 1: How do I restrict the user from entering special characters into certain fields in the InfoPath Form?

    Note: This example assumes you are running InfoPath 2003 with the SP-1 feature enhancements enabled. [Added 6/21/04]

    The easiest way to do this is to use pattern for data validation. For example, you might want a user to enter data in the ###-##-#### format for the Social Security Number field. If the user’s input does not match this format, you may want to throw an alert. You can achieve the above by doing the following:

    1. In Design mode, insert a Textbox Control
    2. Double click on the Textbox Control to get the properties dialog box
    3. Click on Data Validation | Add
    4. Choose “does not match pattern” from the second dropdown and “select a pattern” from the third dropdown
    5. Click on “Social Security number” from the standard patterns dialog

      Picture of the Data Entry Pattern dialog
    6. Click OK to accept the changes
    7. In the Data Validation dialog, choose “Dialog box alert” from the Error alert type dropdown and specify some alert message

      Picture of the Validation dialog
    8. Click OK to accept the changes
    9. You can test your form by clicking on the Preview Form button, in the toolbar  

    Example 2: I cannot put a double quote (“) or an apostrophe (‘) in the pattern builder. How do I validate data against a pattern that contains a double quote (“)?

    You can validate data against a pattern that contains double quotes by using Jscript regular expression. For example, you might want a user to enter data in the “###” format (a pattern contains double quotes) for a field. If user’s input does not match this format, you may want to throw an alert. You can achieve the above by doing the following:

    1. In Design mode, insert a Textbox Control
    2. Double click on the Textbox Control to get the properties dialog box
    3. Click on Data Validation
    4. In the Script section, choose “OnAfterChange” from the dropdown and Edit

    Picture of the Data Validation dialog

    1. Add the followings to your code  

    function msoxd_my_field1::OnAfterChange(eventObj)


    // Write code here to restore the global state.

                    if (eventObj.IsUndoRedo)


    // An undo or redo operation has occurred and the DOM is  read-only.




    // A field change has occurred and the DOM is writable. Write code here to respond to the changes


                    // Specify your pattern using Jscript regular expression

                    var re1 = new RegExp(“\x22\\d\\d\\d\x22”);


                    // Get the field value

    var s = XDocument.DOM.selectSingleNode(“my:myFields/my:field1”).text;


    // Find a match within string s

    if (re1.exec(s) = = null && eventObj.Operation = =  “Insert”)

                    XDocument.UI.Alert(“User input does not match the required pattern”);



    1. After editing all the code, click OK to accept the changes
    2. You can test your form by clicking on the Preview Form button, in the toolbar
  • Microsoft InfoPath 2010

    Calling SelectText (and other InfoPath methods with optional parameters) in C# or VB.NET


    In the introduction to SP1, InfoPath added C# support. One issue that some people may run into is that certain OM calls have optional parameters. One such method is the SelectText() method in the View object. The context ID is optional and it not always easily found. In JavaScript of VBscript, the optional parameter would just be omitted and everything would work. In managed code (C# and VB.NET), you cannot omit optional parameters. To get around this, managed code has System.Reflection.Missing.Value which can be used in place of the optional parameter. This will achieve the same result as omitting optional parameters.

  • Microsoft InfoPath 2010

    Collapsible Sections


    Collapsible Sections


    Mark asks:


    How do I create a collapsible section? That is, a section that can show/hide child controls, whether they are required or not. I can't use an optional section, because it requires binding.


    The easiest way to do this is to this is using Conditional Formatting. Select the Section control, then pick Format | Conditional Formatting.... Add a rule where the formatting is “Hide this control”.


    Adding conditional visibility to a section


    We often call this “conditional visibility.” Like everything in InfoPath, the view state is driven entirely by the data, so you need something in your data which maps to the expand/collapse state. One common approach is to add an attribute field to the group element the section is bound to. It shows up in your data when saved, and the expand/collapse state is saved when users save the form.


    Designing a collapsible section


    Bind a checkbox to the attribute, and you now have UI which lets the user control the state. If you prefer a button, you can create a rule which sets the value of the attribute; use two buttons with more conditional visibility rules to swap the label (e.g. between a + and a – to look like a TreeView). You can also write code which modifies the value of the attribute, and the section will show or hide.


  • Microsoft InfoPath 2010

    Understanding the InfoPath SP1 URN Form Conflict Dialog


    Background on URNs

    InfoPath SP1 included changes to the mail deployment model to allow for easier ways to distribute form templates to a group.  One of the tools for making this deployment model work is the URN (Uniform Resource Name).  These URNs are generated automatically by InfoPath and should be unique for each new form template you build. 

    Note:  It’s possible to get a URN that’s identical to an existing one, but not very likely.  This will be explained more later on.

    To see the URN for your form template, you can select ‘File | Properties’ when in the Designer.  The URN is listed there as the ‘Form ID’.  It is called a Form ID because it is used in the deployment model to identify a form template that may be opened from different locations.  The URN is generated by combining three sections separated by semicolons based in part on the form template’s properties.  Here’s a sample URN:


    It consists of three parts:

    • Prefix:  [urn:schemas-microsoft-com:office:infopath]
    • Form Name (the filename by default):  [blogsample]
    • The Namespace or Namespace Timestamp:  [-myXSD-2004-05-19T20-48-18]

    Note:  The Namespace Timestamp is used whenever a user starts out building the schema within InfoPath.  If a form template is built from an XML or XSD file which has its own Namespace, then that Namespace will be used. 

    The Conflict Dialog

    Picture of the URN conflict dialog 

    This dialog will appear any time that you open a form template on your machine that has a URN that matches an existing URN that you’ve previously opened and cached, but references a different Access Path (or publish location, URL).  As you can see in the example above, I have a file called ‘blogsample.xsn’ that I’ve opened from My Documents, but the conflict dialog is saying that I’ve previously opened a file with the same URN from my Desktop.  I got myself into this situation by publishing the same form template to two separate locations with the same filename and then opening each of them.  Because the Form Name and Namespace timestamp are identical for both XSNs, so is the URN. 

    There are two options at this point.  I can either open the newer template (Version by clicking ‘Replace Form on Your Computer’ or the older one (Version by clicking ‘Keep Form on Your Computer’.  It is important to note that this dialog does not affect the original copies of these files in any way.  It will only update your local cache and it will update the file that is shown with this Form Name in your Fill Out a Form dialog.

  • Microsoft InfoPath 2010

    Layout Tips & Tricks


    2D vs. Flow

    One of the first things that experienced form designers will notice when using InfoPath is that layout of controls is not on a 2D design surface – it’s what we call “flow-based”. Controls function like images – or even character glyphs – in an application like Word. You can drag them around and insert them between words and use blank lines or spaces for positioning. To those designers who are used to precise layout using pixel grids or absolute coordinates, this can be disconcerting.

    To experienced web designers, however, this model is very familiar. Web pages have to be designed to layout dynamically based on the target device. When you’re designing a web page you simply don’t know how wide the browser window which will eventually display the page is, how large the fonts are for the user viewing the page, or even what color settings are applicable. And, of course, different browsers display the same content differently even if all other variables are the same.

    InfoPath templates face a similar set of challenges – but in this case, it’s the data and the form that is dynamic. A variable number of records can appear, parts of the form can show and hide, and users can type different amounts of text into controls which grow. A fixed 2D layout for controls simply wouldn’t work.

    Couple that with a desire to have our views be compatible with web standards (XSLT outputting XHTML), and you can see why we built InfoPath with a flow-based layout mechanism.

    Layout Tables

    A lot of the coolest features in the various Office System applications are likely to fall into two buckets: either you’ve never heard of them, or you couldn’t live without them. Here are a few: Format Painter, Styles & Formatting, Fill Down, and Pivot Tables. Once you’ve used any of those, it’s hard to imagine not having them.

    Tables for layout are like that.

    Web designers know that the trick for good dynamic layout is to use tables. Rather than absolute positions, tables allow for 2D layout of controls by expressing constraints and relative positioning. Even tools like the WinForms designer in Visual Studio .NET are moving in this direction, encouraging the use of docking and panels instead of Top/Left/Width/Height. This makes layout tweaks easier and can even make things like localization much more straightforward.

    A few tips for creating layout using tables:

    • If you’re copying an existing paper form, try sketching out a grid for it using a pencil and a ruler. Count how many rows and columns you need, insert that table, and then start inserting controls into the appropriate cells.
    • InfoPath provides a Layout task pane in design-mode which helps you get started using tables, and exposes some of the actions like Merge and Split Cells in a more convenient fashion.
    • When you drag a control into a table cell its width will be set to 100% automatically. Consider using separate cells for static text and for controls.
    • If you are working from a schema, try dragging a group into the view – for example, “myFields”. One of the options should be Controls in Layout Table which automatically creates a two column table with a standard form layout, containing controls with width set to 100%. You can resize the controls automatically by resizing the layout table.

    In the InfoPath 2003 SP-1 Preview we’ve added a few more table features:

    • a “fly-out” Insert Table button on the toolbar to make getting just the right table into the view easier
    • Draw Table – which definitely fits in with the Format Painter as one of the lesser known but essential tricks in your form design arsenal

    If you’ve never used the Draw Table tool, you should try it. Select Table | Draw Table. This will show the Table toolbar, and enter a mode where you can drag out a rectangle using the mouse to create the first cell, and then draw lines across it to split the cell into two. Keep drawing lines to keep splitting cells. You can change the Border Style on the toolbar to change the style of the borders you create, or use the Eraser tool to erase borders – merging cells.

    Layout “Grid”

    Here’s a cool trick from the team. In the SP-1 Preview, there exists the availability to include a background image.  Here’s a sample grid image:

    Copy the above image and save it to your system as a bmp (no loss in fidelity).  Now go into the View properties dialog, click on ‘Use a background picture’.  In the ‘Files of type’ dropdown, select ‘All Files (*.*)’ and finally select the grid image you just saved.  Back in the View Properties dialog, check “Tile horizontally” and “Tile vertically”.  Click OK.

    Now you have yourself a grid by which to align your controls and text by – this is especially useful when aligning controls between layout tables, aligning tables themselves, or in cases where tables just aren’t appropriate.  When you are ready to publish the form, just go back to the properties dialog and take out the background image.   

  • Microsoft InfoPath 2010

    How to put an image on a InfoPath Button, the KB, and more


    The Microsoft Knowledge Base is an amazing source of content and "How To" type articles, not just a place to go when you think you're seeing a bug.

    Here's one such "How To" article - how to put an image on a Button control:;en-us;832511

    And check out the InfoPath 2003 Support Center:;EN-US;infopath2003

    It features:

    • Highlights & Top Issues
    • Step-by-Step Instructions & How To Articles
    • Links to Downloads, Updates & Utilities

    Also, just a reminder - if you have a question about InfoPath (using it, developing with it, etc) a good to get support is to use the newsgroup microsoft.public.infopath (or try the web interface). The InfoPath team will try and respond to questions posted to the blog comments, but you're more likely to get a quick answer from someone on the product or support team, or another member of the community - like our awesome MVPs - by using the newsgroup.


  • Microsoft InfoPath 2010

    Digitally Signed Fully Trusted Form Templates


    In the InfoPath 2003 Service Pack 1 Preview you can create a fully trusted form template by signing the XSN with a code signing certificate.  Here’s what you do:


    • While in the InfoPath designer, select Tools | Form Options | Security
    • Uncheck the “Automatically determine security level based on form’s design
    • Select Full Trust
    • Click the Sign this form button

    At this point, you need to choose a certificate that can be used for code signing.


    If you do not have a certificate, you can choose the Create Certificate button.  This will create a test certificate – not a certificate that has been authenticated by a certificate authority.


    While you are developing your form template, you will not be able to preview with full trust permissions unless you register the form template. 


    The first time your users fill out the form that you have signed with a certain certificate, they will see a Security Warning dialog that notifies them that the form template is digitally signed and asks if they trust the publisher.  Once they have checked the box to trust the publisher, they will be able to open any form template that asks for full trust and is signed with that same certificate.


    You can view the list of trusted publishers in the SP1 version of InfoPath by selecting Tools | Options and clicking on the Trusted Publishers button.


    If users find that the option to trust the publisher is disabled, that means that the root of the certificate used is not trusted on the user’s machine. 


    When you received your code-signing certificate, you asked the CA (Certificate Authority) for it. What the CA delivered to you is a certificate that is now in your personal folder that is trusted by you and by anybody who trusts the CA that issued it.  So, for example, if you get a code signing certificate from Verisign, any user will have the option to trust you as a publisher as long as they also have Verisign in the list of Trusted Root Certification Authorities on their machine.  Once a user has trusted the root of a certificate, the option to trust the publisher will be enabled in the Security Warning dialog that is displayed when they fill out a fully-trusted, signed form.


    Users can trust the root of a certificate through the Security Warning dialog that comes up when they open a form template.  When the Security Warning dialog is open:


    • Click on the Details button
    • Click on the Certification Path tab
    • Click on the CA Root Certificate
    • Click View Certificate button
    • Click Install Certificate
    • Follow through the Certificate Import Wizard
    • After the import is successful, close out of all of the dialogs
    • Open the form to fill out again and when the Security Warning is displayed the option to trust the publisher should be enabled.



  • Microsoft InfoPath 2010

    Modifying InfoPath manifest.xsf file from script (5/5)


    Part 5 of 5: The final function


    And the final function is


    function FixupSolutionXSN(








          var XsnInputPath = Combine(inputDirectory, xsnInputName);

          var XsfInputPath = Combine(inputDirectory, "manifest.xsf");

          var XsfOutputPath = Combine(outputDirectory, "manifest.xsf");


          ExtractFilesFromXSN(XsnInputPath, outputDirectory);

          FixupXSF(XsfInputPath, XsfOutputPath, serviceURL, wsdlURL);

          MakeXSNFromFiles(inputDirectory, "manifest.xsf", outputDirectory, xsnOutputName);



    Now the gentle reader has free reins to drive the code above to the helpful utility.


    Converting the script to managed code would be a good exercise as well.



  • Microsoft InfoPath 2010

    Modifying InfoPath manifest.xsf file from script (4/5)



    Part 4 of 5: Repacking the XSN


    For packing algorithm we will use another useful utility from the Cabinet SDK which called “makecab.exe”. It can be found in the same place where extract.exe lives.


    This utility needs some data description file that we will build automatically from the XSF file.


    var MakecabExeLocation = "%SystemRoot%\\SYSTEM32";

    var MakecabExe = Combine(MakecabExeLocation, "makecab.exe");


    function SaveToFile(data, filePath)


          var Fso = new ActiveXObject ("Scripting.FileSystemObject");

          Fso.CreateTextFile(filePath, true);

          var TextStream = Fso.OpenTextFile (filePath, 2);





    function MakeXSNFromFiles(






          var DDF = "";

          DDF += ".Set DiskDirectoryTemplate=\r\n";

          DDF += ".Set CabinetNameTemplate='"

                + Combine(outDir, xsnName) + "'\r\n";


          var Dom = new ActiveXObject("msxml2.domdocument.5.0");


          Dom.validateOnParse=false; // for ignoring xsi:nil errors..

          Dom.load(Combine(inputDirectory, xsfName));


                      "xmlns:xsf='" + XsfNamespace + "'");


          DDF += QuoteStr(Combine(inputDirectory, xsfName)) + "\r\n";

          var Filelist = Dom.selectNodes("//xsf:files/xsf:file/@name");

          for (var i=0; i<Filelist.length; i++)

                DDF += QuoteStr(Combine(inputDirectory, Filelist(i).text))

                      + "\r\n";


          var DDFPath = Combine(outputDirectory, "makecab.ddf");

          SaveToFile(DDF, DDFPath);


                + " /v1 /f " + QuoteStr(DDFPath)

                + " /L " + QuoteStr(outputDirectory), true);



    In the last fifth part of the discussion we will come up with the final function.

  • Microsoft InfoPath 2010

    Modifying InfoPath manifest.xsf file from script (3/5)


    Part 3 of 5: Modifying the XSF


    Because manifest.xsf file is just a plain xml file, the easiest way to modify it is to open it in an XML DOM, find the corresponding attributes with XPath, and replace their existing values with new data.


    We will divide the process in two functions. The first one will be responsible for opening and saving the xml file. The second one will find and modify the attribute value.


    The serviceURL and wsdlURL parameters are strings with values like “http://mywebservice” and “http://mywebservice?WSDL” accordingly.


    var XsfNamespace =


    var XpathToServiceUrl =


    var XpathToWsdlUrl =



    function FixupXSF(xsfInputPath, xsfOutputPath, serviceURL, wsdlURL)


          var Fso = new ActiveXObject ("Scripting.FileSystemObject");

          var Dom = new ActiveXObject("msxml2.domdocument.5.0");



          Dom.validateOnParse=false; // for ignoring xsi:nil errors..



                      "xmlns:xsf='" + XsfNamespace + "'");


          // serviceURL

          if(serviceURL != null)


                ModifyAttribute(Dom, XpathToServiceUrl, serviceURL);



          // wsdlURL

          if(wsdlURL != null)


                ModifyAttribute(Dom, XpathToWsdlUrl, wsdlURL);



          if (Fso.FileExists(xsfOutputPath))

                Fso.DeleteFile(xsfOutputPath, true);     




    function ModifyAttribute(dom, xpath, value)


          var AttributeList = dom.selectNodes(xpath);

          for (;;)


                var Attribute = AttributeList.nextNode();

                if(Attribute == null)


                Attribute.nodeValue = value; 




    The XSF file was modified. Now we should restore our XSN and we will do it in the next part of the series.


  • Microsoft InfoPath 2010

    Modifying InfoPath manifest.xsf file from script (2/5)


    Part 2 of 5: Unpacking the XSN

    To unpack XSN one should use extract.exe utility. It can be found in the %SystemRoot%\system32 directory or in the Microsoft Cabinet Software Development Kit. For the command usage details just run “extract /?”.

    In this part we will also introduce several auxiliary functions that will be extensively used throughout the entire discussion topic.

    var ExtractExeLocation = "%SystemRoot%\\SYSTEM32";

    var ExtractExe = Combine(ExtractExeLocation, "extract.exe");


    function Combine(dir, file)


          return dir + "\\" + file ;



    function QuoteStr(string)


          return ("\"" + string + "\"");



    function Exec(string, flagWait)


          if (flagWait == null)

                flagWait = true;

          var WScriptShell = WScript.CreateObject("WScript.Shell");

          return WScriptShell.Run(string, 0, flagWait);



    function ExtractFilesFromXSN(xsnInputPath, outputDirectory)


          var Parameters;


          // add the location to place extracted files,

          // a flag "/Y" that prevents prompting before overwriting

          // an existing file, and a flag "/E" that orders to

          // extract all files

          if (outputDirectory != null)

                Parameters = " /Y /E /L " + QuoteStr(outputDirectory);



                + Parameters

                + " " + QuoteStr(xsnInputPath), true);


    Now we have a tool to unpack XSN. All of the InfoPath form template files are accessible for changing. In the next part of the series we will be modifying the manifest itself.

  • Microsoft InfoPath 2010

    Modifying InfoPath manifest.xsf file from script (1/5)


    In this five part series we’ll show the reader how to programmatically manipulate InfoPath form templates.

    Part 1 of 5: The story

    There are many scenarios where you might need to modify an InfoPath form template (.XSN) after it’s already in use. Let’s say the URL of your Web Service changes.

    With InfoPath 2003 you need to change the URL manually:

    1. Open the form in design-mode (e.g. Right-click on the XSN and select Design).
    2. Extract files of the form template (XSN) into the temporary directory using File | Extract Form Files…, then close InfoPath
    3. Find manifest.xsf in the directory and open it in Notepad (or some other text editor).
    4. Find and replace all instances of existing URL with the new one.
    5. Save the modified manifest.xsf.
    6. Right-click the modified manifest.xsf, select Design, and finally use File | Save As... to save the form template as a XSN file.

    With InfoPath 2003 with Service Pack 1 (SP1), just open the form in Design mode, go to Tools menu, select Change Data Source, and in the wizard locate the new URL.

    But this isn’t (just) a sneaky way to convince you to download the SP1 Preview.

    What if you are responsible for maintaining hundreds of InfoPath forms which rely on the Web service? Even with SP1 this would be a lot of work. It would be nice to do it programmatically.

    The good news is that this is possible, even without SP1. The InfoPath XSN format is really a CAB file, and the files that make up the template are XML files which can easily be modified programmatically. You can pack/unpack a CAB file with help of extract.exe and makecab.exe utilities that are accessible for Windows users. Now the only things you need is to implement a small utility using script or managed code that will do the described above sequence automatically. Inside of the utility you should do the following:

    1. Unpack XSN file using extract.exe utility to the local temporary directory.
    2. Find manifest.xsf file and open it as a plain XML file.
    3. Replace the corresponding URLs using the XML DOM.
    4. Save the modified manifest.xsf.
    5. Pack all files into the XSN using makecab.exe utility.
    6. Clean up your temporary directory.

    If you write a wrapper around this process to enumerate all the form templates, your hundreds of forms will be updated just in a few minutes.

    Using this approach you can change not only URLs but SQL connection strings, files names, etc. If you want to learn more about the XSN format and the files that make it up, check out the InfoPath 2003 SDK. As always, be careful – save backup copies, test your code, test the templates before and after, etc.

    At the end of this discussion, the patient reader expects a good sample that supports the idea explained above. And we will definitely do it in the following parts 2-5 of the series.

    To be continued.


  • Microsoft InfoPath 2010

    Converting a Data Source


    For anyone who has developed an InfoPath form template against a schema, database, or Web service that has changed since the form template was initially created, the following should be some good news.  The SP1 Preview Release of InfoPath contains the ability to provide InfoPath with an updated version of your schema or data source and InfoPath will update your solution accordingly.  That’s right, gone are the days of hand modifying the XSF, template file, XSL, etc. in order to change the schema.  You can change your main data source via the ToolsàConvert Main Data Source menu entry or a data connection via the modify button for that source in the ToolsàData Connection dialog.

    When you provide InfoPath the updated data source, InfoPath will update the schema files stored in the form template and look for and apply changes between the old and new data source.  In particular InfoPath will look for type changes, cardinality changes, namespace changes, adds, deletes, renames, and move operations.  For any recognized operation, all existing bindings in the view, XSF, and event handler hookup will be fixed accordingly (note, it is still your responsibility to fix business logic code.)  Unfortunately InfoPath is not omnipotent, so it might not be the best idea to wait until you have renamed, moved, and extremely modified the children of an element before providing the updated schema to InfoPath ;-)

    (And if a menu option to update your data source isn't convenient enough, tomorrow we'll start a five part series on the InfoPath Team Blog showing you how you can automate this sort of operation by taking advantage of InfoPath's XML-based form template file format.) 

  • Microsoft InfoPath 2010

    The documentSchemas element in the XSF


    A few customers have run into an unspecified error when attempting to add service pack features to an RTM form template when using the InfoPath SP1 Preview Release design mode.  For anyone who has created a form template outside of InfoPath or added/changed the schemas for a form template by hand this might be an interesting read.

    There is a section in the XSF called the documentSchemas section that is used to define all the namespaces and their corresponding XSD schema for the form template.  Here is the documentSchemas element InfoPath creates for a form template that uses two namespaces “http://root” and “http://imported”, each with its own schema:

        <xsf:documentSchema rootSchema="yes" location="http://root root.xsd"></xsf:documentSchema>
        <xsf:documentSchema location="http://imported imported.xsd"></xsf:documentSchema>

     Note that in this case, the root element of the form template comes from root.xsd and its documentSchema entry has an attribute “rootSchema” with a value of “yes”.  The documentSchemas section should contain an entry for every namespace that is used in the main data source for the form template; herein lays the problem.  The InfoPath team has seen a number of form templates where schemas were added outside of InfoPath but the documentSchemas section was not updated accordingly.  Depending on whether you are the glass half empty or half full type of person, the RTM version of InfoPath didn’t mind this but the SP1 Preview Release does.

    That should suffice to explain the issue; where does that leave you?

    • If you have never hand modified schemas or the XSF in RTM then don’t worry, you have no issues
    • If you have done this and are having issues upgrading your form template in the SP1 Preview Release then you should ensure your documentSchemas element is up to date with the schemas in your form template
    • If you have done this and are reading this post as an archived article then you may not see any issues since we are working around this issue in post preview release builds.  However, there are potentially some features that will be lost since we are essentially reverting to RTM behavior for the data source (such features as seeing choice nodes in the data source pane and adding an entire schema to an open section of the data source may be disabled in this case.)  You should make sure the documentSchemas section is correct before upgrading the form template.

    With all that said there is some pretty good news – with the SP1 Preview Release you can now provide an updated schema to InfoPath and we will update the form template accordingly.  This will be the topic of another blog entry soon!

  • Microsoft InfoPath 2010

    Having more control over Page Breaks using Conditional Formatting

    When printing forms, sometimes it might be desired to have more control over where Page Breaks should occur. For example, you might want a Repeating Table to start printing on a new page once it has reached a certain number of rows or you might wish to provide a way for users who are filling out forms to be able to insert/remove Page Breaks in certain locations of the form. You can accomplish this using Page Breaks (available with SP1) with Conditional Formatting.
    Example 1: Allow users to insert a Page Break when a Checkbox is checked
    1. In Design mode, insert a Checkbox Control, type "Insert Page Break" next to the checkbox.
    2. Insert a Section Control (From the Control Task Pane, click on "Section")
    3. Within the Section Control, insert a Page Break (Place the cursor inside of the Section Control you just inserted and from the menu Insert | Page Break)
    4. Double click on the Section Control to open the Section Properties dialog. Select the Display tab and click on the Conditional Formatting button.
    5. Click  Add... to set a new condition, which will keep the Page Break "hidden" unless the checkbox is checked, to do this: Select the name of the checkbox in the first condition drop-down and set the condition "is equal to FALSE". Check the "Hide this Control" checkbox and close all open dialogs by clicking "Ok"
    6. You can test your form by clicking on the Preview Form button, in the toolbar.
    Example 2: Start printing a Repeating Table in a new page once it has more than 3 rows
    1. In Design mode, insert a Section Control (From the Control Task Pane, click on "Section")
    2. Within the Section Control, insert a Page Break (Place the cursor inside of the Section Control you just inserted and from the menu Insert | Page Break)
    3. Place the mouse cursor beneath the Section Control and insert a Repeating Table (From the Control Task Pane, click on Repeating Table).
    4. Double click on the Section Control to open the Section Properties dialog. Select the Display tab and click on the Conditional Formatting button.
    5. Click Add... to set a new condition, which will keep the Page Break "hidden" unless the number of rows in the "Repeating Section" exceeds 3, to do this: Select  "The expression" in the first condition drop-down and type the following XPath expression referring to the Repeating Table, "count(../my:group2/my:group3) <=3" in the text field next to it. Check the "Hide this Control" checkbox and close all open dialogs by clicking "Ok"
    6. You can test your form by clicking on the Preview Form button, in the toolbar.
  • Microsoft InfoPath 2010

    Using Custom Controls that don't fire OnPropertyChange Notifications in InfoPath


    InfoPath has a really powerful feature to allow users to create their own custom controls for InfoPath forms using Microsoft's ActiveX technology. One requirement that is essential for controls to work as expected in InfoPath is that the controls must fire OnPropertyChange Notifications so that InfoPath knows to grab the information and copy it into the XML DOM. The unfortunate thing is that there are some already built controls which don't fire OnPropertyChange Notifications but they would be incredibly useful in an InfoPath form.

    Here's what to do if you want to use these types of controls. InfoPath will grab the value before you save, so if you don't need other parts of the form to interact with the data from the ActiveX control, then you don't really need to do anything. Your data from the ActiveX control will always get saved.

    If you do need to pull data from the ActiveX control before it is saved (maybe for example on a OnAfterChange or a button click), you should call XDocument.ForceUpdate(); before grabbing the value. This will cause InfoPath to query the ActiveX control for the value and place it into the XML DOM so then your business logic will be able to get the correct value.

  • Microsoft InfoPath 2010

    InfoPath Quick Tip: Exporting InfoPath forms to Word


    Want to export your InfoPath form view to a Microsoft Office Word document?

    The easiest way to do this is to export your InfoPath form to an MHT file using File | Export To | Web... while filling out your form. Then, just open the MHT file in Microsoft Office Word.  The Word document that you create based on the MHT file exported from InfoPath will look very similar to the InfoPath form itself.

  • Microsoft InfoPath 2010

    InfoPath Quick Tip: Object Model Help


    When writing script in the Microsoft Script Editor (MSE), you can quickly locate help on the InfoPath Object Model by positioning the cursor on a keyword (object, method, property) and hitting F1. This can save browsing through help.

    (We weren't able to hook up IntelliSense in MSE, so knowing this F1 trick is a big help when doing VBScript or JScript development with InfoPath. If you download the InfoPath 2003 Service Pack 1 (SP1) Preview and try out the InfoPath 2003 Toolkit for Visual Studio .NET you'll find full IntelliSense integration when writing managed code for InfoPath projects.)

  • Microsoft InfoPath 2010

    Decoding the InfoPath picture format (also Ink Picture)


    InfoPath provides two controls which saves pictures inside the XML form (rather than linking to it). When trying to process this XML file outside of InfoPath, you will need to translate the data back into the image binary. InfoPath picture control data and ink picture control data is stored in the XML as base64 encoded data. You will need to decode the base64 picture into binary before it is usable.

    Below is a code sample in C# that will do it:

    byte[] image = Convert.FromBase64String( s );
    MemoryStream memStr = new MemoryStream();
    memStr.Write( image, 0, image.Length );
    Image img = Image.FromStream( memStr );
    img.Save( filename );

  • Microsoft InfoPath 2010

    Executing menu and toolbar commands from the InfoPath Object Model


    While the InfoPath 2003 SP-1 object model is quite extensive, it doesn’t provide all the functionality that is exposed through the InfoPath menus and toolbars. However, you are not limited by that fact. Using the CommandBars object, you can access any of the functionality available in menus and toolbars.

    For example, the InfoPath object model exposes a Print method but not a PrintPreview method.  However, that doesn’t mean that you can’t access this functionality.  Using the CommandBars object, you can execute the Print Preview functionality available on the Standard toolbar like so:

    Application.ActiveWindow.CommandBars(“Standard”).Controls(“Print Preview”).Execute();

    The list of available command bars is on the View | Toolbars menu. If you want to access a menu item, use “Menu Bar” for the command bar name. The control name to use is the same name that appears on a menu or in the tooltip when the mouse is hovered over a toolbar button. (Please refer to MSDN ( for more information about the CommandBars object.)

Page 11 of 12 (298 items) «89101112