This will become my list where I log some of the issues between running a form with an InfoPath rich client versus inside of SharePoint Form Services, outside of the warnings given within the designer. Please be welcome to share yours as well. I am sure there are a ton out there that Microsoft has not documented and it will be helpful to everyone to have a repository for this information.
1. Rules on Controls
Rules on a control run differently in the rich client compared to form services. In the rich client the rules run as "on-click" events where as in form services they run as "on-load" events. This is strange since rules are allowed in form services, you think that they would act in the same manner. The workaround for this issue is for the rule set not to run on load there has to be a condition defined on the rule, even it is a bogus condition that will always return true.
2. Closing a Form
Closing a form should be a simple matter to understand, except in the rich client the form actually closes and goes away. In form services when the form is closed a message is shown stating the form has been closed. What form services does allow you to do what I have found is provide a "Source" querystring attribute in the URL when opening the form in the browser. The value for this attribute is used when the form is closed to redirect the browser. So, the workaround I did for this issue was to create a basic HTML page that informs the user that the information has been saved and provide a link back to the form. On the forms I want to actually close the browser windows, I include a javascript statement that just does a windows.close() call and provide a link to these HTML pages in the Source attribute where needed.
3. Form Template Parts
With InfoPath 2007 you have the ability to create custom form template parts. These allow a designer to create a "control" for use in multiple InfoPath forms. Form template parts are convienent and work in all flavors of compatability in InfoPath 2007. What it is lacking is the ability to have custom managed form code in a template part. It allows rules, but no programming of managed code. So even though the framework can be shared in the template, the code has to be written in the InfoPath form itself.
4. Document Information Panels
With InfoPath 2007 you have the ability to create custom document information panels for use in Word, Excel, and Powerpoint when working with SharePoint fields. Of course with InfoPath comes restrictions on what you can and can't do when developing document information panels. The following list outlines some of the issues that came up when developing in a document information panel
-
Cannot add or edit the main datasource
-
Any control added to the form has to bind to an item in a datasource
-
Multi item select region does not work. This is mainly because the control has to be tied to a repeating item in the main datasource. This is because the control will add/remove nodes in the repeating group as items are checked. The control cannot add/remove nodes to a secondary datasource. Since you cannot modify the main datasource, you cannot use this control in a document information panel.