SharePoint Development & Administration + InfoPath

Overview: When added to an InfoPath Form template, the following JScript allows data to be transferred from one form to another programmatically using code executed by the first form. For example, this can allow a set of data from a forms data sources to be extracted and transfered into another form containing similar fields. This can also allow variations, or custom versions of a form template to be sent to specific people who may speak a different language, require an alternate layout or theme, or if the data containined in the form is confidential and needs to be submitted to a secure or different location to other forms of the same type. Alternative Methods for Transferring data between forms (without using code) Requirements: - InfoPath 2007 (can also be acheived using 2003) Process: The step descriptions below have been commented out to allow them to be pasted into the forms code. Additional notes are in blue and have also been commented, but can be ommited if required....

SharePoint Designer Workflow: How to test if a specific value exists in any item in a list without the workflow stopping due to a "List item not found" error if no items exist with the required value. When trying to find a list item using the "Update List Item" action or similar in a SharePoint Designer workflow by matching a field which is not always unique (eg. the "Title" column/field), the workflow will stop if the list item is not found with a "List item not found" error. To prevent this, a looping workflow can be used to build a delimited string containing the value from the field being tested, for all items in the list. Instead of trying to test if a specific value exists in any item in a list by testing the required field directly, the workflow can compare the string containing all possible values using a much larger range of useful conditions including "contains", "does not contain", "contains (ignoring case)...

When should code be used in an InfoPath form and when should it be avoided? There is no simple answer to this question, as it comes down to a matter of personal preference. This article is aimed at reducing the development time for InfoPath forms of various scales. The following are some tips to help you make the right decision. Firstly, I should note that InfoPath is a great tool for creating electronic forms, as many features are provided to including data connections to external sources (Database, SharePoint, etc.), data validation and conditional formatting which allow complex forms to be created and submitted without using any code. I my opinion, as an InfoPath form becomes more complex the efficiency of the form's development is reduced when avoiding using code. This is due to the amount of mouse clicking required to set default values, create rules and apply formmating conditions to individual elements in a data source, or controls on the form template. If code is not a stre...

When an InfoPath form has a large number of SharePoint data connections, the time it takes to open a the form will increase resulting in slow loading time when the form is being opened. To reduce the loading time of the InfoPath form, SharePoint list/library Views with filter criteria can be used to minimise the number of results, while ensuring that all required items that are displayed in the result set. [edit] InfoPath Data Connections to a SharePoint list retrieve items from the list's default view. This can lead to the data connection not returning the required result from the SharePoint list if items are filtered or limited. See InfoPath data connection not returning all results from a SharePoint list for details. For instructions in how to create and set up InfoPath data connections to retrieve data from SharePoint lists, see Using Secondary InfoPath Data Connections to retrieve data from a SharePoint List or Library . The challenge when creating views to ignore irrelev...