Microsoft Office 2003: Microsoft InfoPath 2003 Performance tuning

Overview of the solution:

The Solution here highlights how a Microsoft technology is used in critical business problems using solutions built with the Microsoft Office System. Microsoft InfoPath 2003 is one of the new office tools available with Microsoft Office 2003. Microsoft InfoPath 2003 gather information flexibly and efficiently in rich, dynamic forms and more effectively share, reuse, and repurpose information throughout your team or organization. InfoPath 2003 helps improve collaboration and decision-making to positively impact your business. While developing solutions using InfoPath 2003 most of the developers will face this performance issues and struggle to overcome from it, here in this article I provide some of the valuable tips and tricks that will definitely increase your InfoPath 2003 solution’s performance.

InfoPath 2003 Performance tuning tips and tricks:

If the view contains many controls, and especially if they are repeating controls such as repeating tables and repeating sections, you should separate the view into multiple views to reduce the amount of HTML rendering that InfoPath is required to do.

Always try to Use Expression Box to display calculated value, if you don't need to storethat value. If you have business logic to trigger all the calculation, pleaseonly trigger necessary calculation. Triggering large amount of calculationsis costly process.

Rules: About the form XSL, and XSF, anything in the XSF is extremely slow,anything in the XSL is acceptable, or fast, so when we develop a form, we have toreview these files frequently, for example, the conditional formatting goesto the XSL, it is ok, the speed is acceptable. But rules are going to the XSF, then we try to find a way to convert them to C# code, some of the things we do can become C# some not, once it is C# (with the custom event handlers), the speed increases dramatically.

Views: About the multiple views in a form, we found that if the form have one or10 views, does not matter, unless that increases the size of the XSF, then thespeed goes down.

NOTE: Not all the things in the XSF are slow; some of the items are fast

xml DOM: Be cautious while using replace node function on the xml DOM in the C#code, replacing large amount of nodes is very slow, it seams a DOM problem,talking about a 1MB of xml, ironically, loading 10MB of xml in the DOMusing the DOM function is extremely fast, so the speed is different perfunction.

Avoid using more number of tables (data or layout) in any single view. Avoid large repeating data structures that can grow too many pages. Avoid complex nesting of optional and repeatable sections. These are quite complicated to layout and also can quickly cause a single view to become very large.

Be aware of exactly what your business logic does. For example, onAfterChange can fire multiple times for a single edit.

Try to avoid querying data at the form load event. Rather than querying for all the data then having InfoPath just show a small amount, refine your query and only bring the data you plan on displaying into InfoPath. Don’t pre-populate data sources that aren't necessary on load. Don't set up un-used data source. Merge static xml data sources into one if you have multiple xml data connections.

Limit the number of drop-down list boxes that contain many items, especially within repeating controls. Internet Explorer renders each drop-down list box with its own window handle (HWND), and the HTML representation of a drop-down list box with many items is significant.