InfoPath 2003 Form Viewer Sample Application


Introduction

Microsoft Office InfoPath 2003 provides a powerful way of designing and deploying electronic forms to capture information as XML. In order to design, fill-in and view InfoPath forms, Microsoft Office InfoPath 2003 is required to be installed on each PC.

A common requirement is the ability to provide users who do not have InfoPath installed with a way in which they can view a read-only representation of the data in a completed form. One way to do this is the mail-to facility built into InfoPath itself which converts the form to a read-only HTML view, and sends it via email. The question remains however, would it be possible for a user without InfoPath installed to open an unmodified XML file generated by InfoPath from a web site or file share? This sample application shows how the XSLT style-sheets generated by InfoPath itself at design-time could be reused to render a read-only view of the data collected by that form for users without InfoPath. 

 

Download the sample application

 

Note. An alternative approach to this problem is described in Microsoft Knowledge Base Article KB826990. The KB article describes how an InfoPath solution (.xsn) file can be modified at design time so that a reference to an XSLT is included in the XML that InfoPath generates. This means that when it is opened by a user who does not have InfoPath installed, Internet Explorer renders the XML using the spcified XSLT.

 

Sample Overview

An InfoPath solution file (.xsn file) is made up of several other files compressed into a single .xsn file in cabinet file format. The files in the .xsn include:

manifest.xsf           XML Manifest describing the files that make up the solution.

*.xsl                      XSLT style-sheets that describe how each of the InfoPath Views should be rendered.

*.xsd                     XML Schema files for the form and each of the data sources used.

*.xml                     Default and template data for the form.

*.js/*.vbs                Custom script written by the form developer.

 

 

By extracting the XSLT style-sheets from the solution we could easily create an InfoPath viewer application that reuses these to render the data from an XML file generated from an InfoPath form. The application would need to:

1.       Open an InfoPath generated XML file and identify the solution that it was created with. This can be determined from the processing instruction that InfoPath includes in all the XML data that it generates.

2.       Download the solution file and extract the XSLT style-sheets from it using the cabinet extractor, expand.exe, that ships with Windows 2000 and later.

3.       Display a list of views (i.e. XSLT style-sheets) available to be displayed.

4.       When a view is selected, apply the appropriate style-sheet to the XML and render.

 

 

 

Figure 1 InfoPath Viewer sample application

 

System Requirements

·         Microsoft .NET Framework 1.1

·         Microsoft Windows 2000 or later

 

Limitations and Further Enhancements

This sample application has a number of limitations that could easily be addressed with a little more work:

·         It only works with URL-based solutions, not URN-based ones.  If the application determines that the form was created with a URN-based solution it could try and locate the solution file by searching the directory in which the form is located.

·         It only works with XSN solution files, not with extracted (.xsf) files.  If the form references an XSF solution file, the application should look for XSLT style-sheets in the same directory as the XSF file.

·         The XSN file needs to be accessible at the location specified in the PI in the XML file.  If the application cannot locate the XSN file at the specified URL, it could try and locate the file by searching the directory in which the form is located.

·         It doesn't render resources (e.g. pictures) embedded in the solution.  The application could also extract JPG and GIF files from the XSN, and update the XSLT(s) to reference them so that they are rendered in the viewer.

 

Unfortunately I am unable to devote any more time to working on this, however if you like the idea of this sample and you have time to enhance it further, please feel free to start a GotDotNet workspace with this source code.  I only ask that you post a comment here linking to it so that others can get access to the latest version.

 

 

Comments (12)

  1. EROL says:

    Thanks, Great solution to Help the reader of files InfoPath. EROL

  2. Betty Gray says:

    Checking this out

  3. Gerrard says:

    Making ExtractXSNFile a tiny bit more robust should be as easy as:

    System.Diagnostics.Process theProcess = System.Diagnostics.Process.Start("expand.exe", _tempSolutionFile + @" -f:*.xsl " + dir.FullName );

    while(!theProcess.HasExited)

    {

    System.Threading.Thread.Sleep(300)

    }

    If I’m not mistaken.

  4. Gerrard says:

    it’s also pretty easy to hide the console window:

    System.Diagnostics.Process theProcess = new System.Diagnostics.Process();

    theProcess.StartInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;

    theProcess.StartInfo.FileName = "expand.exe";

    theProcess.StartInfo.Arguments = _tempSolutionFile + @" -f:*.xsl " + dir.FullName;

    theProcess.Start();

    while(!theProcess.HasExited)

    {

    System.Threading.Thread.Sleep(300);

    }

    sorry to bomb your comments, I had a tough day and felt like playing with some code.

  5. Mark Bower says:

    Thanks Gerrad. I’ll update the sample on GotDotNet with your changes.

  6. David says:

    InfoJet Service is a Java class library to publish InfoPath Forms to the Web. InfoJet Service can be deployed as Web Services. J2EE and .Net Web application with integration of InfoJet Service support the users to edit InfoPath Forms in Internet Explorer and FireFox.

    http://www.infojetsoft.com

    thanks

Skip to main content