Whenever you want to expose your forms on a web page the tendency is to want to put a plain hyperlink to your XSN form template or XML file. The problem with this ranges from getting lame IE download dialogs all the time to data loss scenarios (see below). The correct way is to do it the way SharePoint does it.
You want to use script to call the inlaunch.dll which InfoPath installs and registers just for this purpose.
Key Scenarios:
-
-
Create a new form from an XSN form template. - For this you call the CreateNewDocument2() method.
-
Create a new form using an existing XML file as the default data. - For this you use an undocumented feature whereby you pass the URL to your XML file to the same CreateNewDocument2() method. Essentially what it does is open that XML file but forces a SaveAs type behavior.
Brief Code Snippet
This example is for the second scenario:
var strTemplateLocation_New = "http://sitename/folder/template.xsn";
var strDefaultSaveLocation_New = "http://www.example.com";
function CreateNewXMLDocument()
{
// Based on WPQ3combineDocuments()
var objOpenXMLDoc = new ActiveXObject("SharePoint.OpenXMLDocuments.1");
var bSuccess = false;
bSuccess = objOpenXMLDoc.CreateNewDocument2(window , strTemplateLocation_New , strDefaultSaveLocation_New );
}
<a onclick="CreateNewXMLDocument(); return false;" style="cursor: pointer;" href="<numbersign>">Create New Blank Form</a>
Note: where you see href="<numbersign>" you need to put in the # symbol inside the quotes instead. I can't show that here because the blog posting system reformats it as code. Best is to just download the sample code directly.
Full Sample Code
I've uploaded a web page with sample code for all 3 scenarios. Download Example: http://www.infopathdev.com/files/folders/examples/entry41177.aspx
Some notes on this example:
-
You will need to swap in your XSN or XML urls for the current placeholders for "DocumentLocation" and "TemplateLocation".
-
The use of 'http://www.example.com' is to just force InfoPath to instead ask the user to save into their MyDocuments folder. You can alternatively specify a hard drive location but wildcards won't work. Also both these methods will result in a browser cross-domain security prompt. To eliminate that you would want to use the same server name as in the actual XSN link. If that is a SharePoint site this will result in InfoPath thinking it can save to that location (which may be true). If it's not a SharePoint site then you're in luck because then InfoPath will treat it like the example.com placeholder and force the SaveAs to MyDocuments but without any cross-domain issues/prompt.
-
You'll notice the hyperlinks have hrefs and the script. This is so that if the user wants to right-click download the target they can do this (for example to save an XML file for offline use). I of course substituted # for the XSN link as downloading the XSN locally makes no sense.
-
LIMITATION: If you use this method to link to a file not on the same domain then you will get a cross-domain security yes/no dialog from Internet Explorer and maybe other browsers. It is because script is trying to access a file on another domain. I currently know of no way around this issue.
MSDN OM Documentation
The following MSDN reference is the complete documentation of this method and explains a couple other advanced calls for other less common scenarios: http://msdn2.microsoft.com/en-us/library/ms452435.aspx
Post Update on 2007-10-22 to explain further an issue around the example.com placeholder.
Post Update on 2007-10-23 to correct the ProgID in the sample htm document to use "InfoPath.Document" instead of "mso-application".