InfoPath Dev

I am new to C# and InfoPath 2007 but pretty experienced with IP2003 and JScript.

One thing I often did in IP2003 was link two forms together programatically - i.e., if a user changes a field in Form X, a field in Form Y was also changed. To do this, I would use two data connections: one to grab Form Y from SharePoint and another to re-submit Form Y to the SharePoint form library. Pretty simple stuff.

For some reason, I can't figure out how to do this in IP2007/C#. I thought this would work:

XPathNavigator receiveFormY = DataSources["receiveFormY"].CreateNavigator();
receiveFormY.SelectSingleNode("//fieldToUpdate").SetValue("NewValue");
FileSubmitConnection ySubmit = (FileSubmitConnection)(DataConnections["submitFormY"]);
ySubmit.Execute(receiveFormY);

However, the new "Form Y.xml" file has the xml declaration and processing instructions stripped out.

I know this scenario can easily be handled using the DBXL product, but can anyone humor me and tell me what I'm doing wrong with my code?
 

Without actually debugging it I could guess that the first CreateNavigator() got positioned at the document element of Form Y, bypassing the PIs.

Two possible ideas:

1. Why do you use the version of Execute() that takes a parameter? What will happen if you just called ySubmit.Execute() instead?

2. If #1 does not work you can try creating a new XmlDocument making sure it has the exact contents you want. Then call CreateNavigator() on this document and pass it to the Execute() method

(Note: I am not familiar with the semantics of Execute, maybe it's meant to only submit the document element and not the PIs... then you'd have to look for a different solution)

David,

That's correct. For whatever reason, CreateNavigator() positions itself at the document element.

The parameterized version of execute allows you to use a data connection to submit data other than the form's main data source.

I will try option #2 and get back. Thanks for the reply.

Chris 

 It turns out that "Only XPathNavigators from a DataObject are allowed" to use Submit Data methods. Great idea, though.

Hey,

You are right. In addition to that it turns that you cannot even replace the outer XML of the navigator of the data object so that solution would not work either.

This problem got me curious so I did some debugging and found a hack that will allow you to do what you need. This involves getting access to the underlying document from the navigator and using it to inject the PIs.

--- Note: this solution requires Full Trust ---

First of all, you will need to add a reference to the IP2003 OM assembly:

C:\Program Files\Microsoft Office\Office12\Microsoft.Office.Interop.InfoPath.SemiTrust.dll

Now let's get to the document:

XPathNavigator receiveFormY = DataSources["receiveFormY"].CreateNavigator();

// Get the Microsoft.Office.InfoPath.MsxmlNavigator's member WrappedXmlNode
IXMLDOMDocument2 document = (IXMLDOMDocument2)receiveFormY.GetType().InvokeMember("WrappedXmlNode", BindingFlags.GetProperty | BindingFlags.Instance | BindingFlags.NonPublic, null, receiveFormY, new object[] { }); 

 

At this point you are holding a fully functional IP2003 document and you can edit it as you please. For example:

IXMLDOMNode piNode = document.createProcessingInstruction(piName, piValue);
document.insertBefore(piNode, document.documentElement); 

 

Once you're done editing, just call Submit() as before:

ySubmit.Execute(receiveFormY);

I am sorry I could not find a more elegant solution for you but this one seems to work (besides the Full Trust requirement). Good luck!

 

 Wow. That works. Suffice to say I would never have figured that out. Thank you so much, David!

You're welcome!

I guess I just need to add a disclaimer that the trick relies on the internal implementation of the Navigator so this is not guaranteed to work in future versions of InfoPath (and might actually not even work on Forms Server - to be verified).

It did not work for me in Forms Server. Unfortunately, I don't have access to the server logs, so I can't do much debugging.

You are correct but here is the interesting thing:

you don't need to do any of this hacking on Forms Server - it seems like the navigator you get from the data source has the proper PIs in that case.

The reason my hack does not work there is because the implementation of the navigator is different.

Now tell me, what is your actual scenario? :)

1. If your form is meant to run only on the client, you can use my hack
2. If your form is meant to run only in Forms Server, you don't need any hacks - the only problem that testing will require deployment all the time
3. If you need both it will be tricky because your business logic links against a client-only DLL that does not exist on your server. You will have to do some late binding work to make sure your own DLL even loads - then you can check if you're running in the server or not and act accordingly.

Good luck with all that!

Dave

Amazing. Again, thanks.

If anyone has a list of behavioral idiosyncrasies between client and web versions of forms, here's another: xml files as secondary data sources do not contain the XML declaration or processing instructions in the InfoPath client, but they do in the browser.
 

Good idea for making a list - I've posted the first two items here and this thread can be used to add more of those whenever they are found:

http://www.infopathdev.com/forums/p/6912/25222.aspx