Responding to Events in InfoPath Forms - Share Point 2010

Carrying on with our Equipment Request form, let’s look at how we can hook up the buttons on the form using a few methods that follow.

Using the Rules Engine
The easiest way to handle events in an InfoPath form is to use the built-in rules engine. Three different types of Rules can be applied to a control or field:

  • Validation Allows users to add a validation formula to a field or control. Where the validation formula does not return true, a user-defined message is displayed.
  • FormattingFormatting works a bit like conditional formatting in Excel. The user can define a condition or formula that must evaluate to true or false. If the formula evaluates to true, the format is applied.
  • ActionWithin InfoPath most event handling is done using Action rules. By using Action rules, a user can perform a series of actions when a specified condition occurs. Some examples of a condition that can trigger an action rule are Field Changed and Button Clicked. We’ll make use of an Action rule to switch to our Customer Search view when the Find Customer button is clicked on our form:
  1. If you haven’t already done so, switch back to the default view: in the Page Design tab of the ribbon, select View 1 (default) from the View drop-down. Then click the Find Customer button.
  2. From the Properties tab’s Button section of the ribbon, select Rules. You’ll see the Rules pane on the right side of the page.
  3. Select New | Action from the Rules pane, and then type the rule name as Do Customer Search.
  4. In the Run These Actions section, click Add |Switch Views, and then select Customer Search Results from the list of views.
  5. As well as showing our search results page, we need to perform the actual query. This time select Add | Query For Data, and then select the Customer data connection from the list.

We can now publish this form and see the results using the browser. When the user clicks the Find Customer button, a list of customers is displayed, allowing the user to select an appropriate record. The next step is to copy the selected customer details into our main form and then switch back.

  1. In the Page Design tab of the ribbon, switch to the Customer Search Results view, and then highlight the Select button.
  2. From the Properties tab on the ribbon, click Add Rule | When This Button is Clicked | Set A Field’s Value.
  3. In the Rule Details dialog, set the Field to the CompanyName field on the Main data source, as shown. The selector can be accessed by clicking the down-arrow button at the right of the Fields text box.
  4. Responding to Events in InfoPath Forms
    Responding to Events in InfoPath Forms

  5. Set the Value to the CompanyName field of the Customer data source. Again this can be done by clicking the down-arrow button to the right of the text box. Click Insert Field Or Group on the Insert Formula dialog that appears to show the selector.
  6. Repeat this process to copy all fields from the d:Customer group into the Customer group of the main data source. Rather than using the Add Rule button in the ribbon, which will create a new rule, you can add an additional action to the current rule by choosing Add | Set A Field’s Value from the Rules pane.
  7. After all the field values are copied, switch back to default view. From the Rules pane, click Add | Switch Views and set the view to View 1. We can now publish the updated form and navigate to the document library to see the fruits of our labor. This time, when you click Find Customer and select a customer from the list, the details are copied into our main form and the search view is hidden from view.

Adding Code-Behind
You may have noticed in our demonstration form that no matter what is entered in the Company Name field, all companies are returned each time the Find Customer button is clicked. Because we’re using a database connection to retrieve our customer details, we don’t have the facility to pass in a parameter using the data connection interface in InfoPath. However, behind the scenes, InfoPath exposes a full object model that allows us to control practically all aspects of the data connection using managed code. By adding a managed code event handler to our Find Customer button, we’ll dynamically modify the SQL query that’s used to generate our search results.

NOTE Using managed code with InfoPath 2010 requires Visual Studio Tools for Applications. This feature can be installed using the Office 2010 setup program. Under Microsoft Office InfoPath, select Visual Studio Tools for Applications in the .NET Programmability Support group. Before we start writing our custom event handler, we’ll modify the rules that we added earlier to prevent the database from being queried twice.

  1. Click the Find Customer button and then in the Rules pane, delete the Query using a data connection action: click the arrow to the right of the action and choose Delete.
  2. From the Developer tab in the ribbon, click the Language button. Make sure the Form template Code language is set to C#. (You can use VB, but the code in this sample is written in C#.)
  3. Switch to the Properties tab, and then click the Custom Code button in the Button section of the ribbon. The Visual Studio Tools for Applications interface will be loaded and a stub method will be created to handle the click event for our button.
  4. Type the following code in the body of the stub method:
string xpath=@"/my:EquipmentRequest/my: Customer/my:CompanyName"; XPathNavigator nav = this.MainDataSource. CreateNavigator(); string companyName = nav.SelectSingleNode (xpath,this.NamespaceManager).Value; DataSource customer = this. DataSources["Customer"]; AdoQueryConnection cnn = customer. QueryConnection as AdoQueryConnection; string allItemsQuery = cnn.Command; cnn.Command =allItemsQuery + " Where C. CompanyName like '%" + companyName + "%'"; cnn.Execute(); cnn.Command = allItemsQuery;

A few items in this code sample require some explanation—first, the xpath variable: As mentioned earlier, InfoPath is an XML-based form designer. On the surface, this may seem trivial, since all developers are familiar with XML and the various objects in the .NET Framework that can be used to work with XML. However, because InfoPath is completely XML-based, things work a bit differently and it can take time to fully understand the difference. In traditional WinForms or ASP.NET programming, the presentation user interface is separate from the data. Often, most of the code that we write involves either reading data from or writing data to controls. Since the presentation layer in InfoPath is simply a transformation of the data (that is, an XSLT transform of XML data), there is no presentation layer to manipulate programmatically. Data is automatically bound to the appropriate controls. If we were writing an ASP.NET application, we may retrieve the value of the CompanyName text box by examining the Text property of the appropriate control; in InfoPath, there is no such control and we retrieve the value of the CompanyName field by querying the data model directly. The most common way to perform this query is to use XPath,and the xpath variable stores the XPath expression that refers to the appropriate field.

TIP InfoPath Designer makes it easy to determine the XPath expression for a particular field. In the Fields pane, right-click the required field and select Copy XPath from the context menu. The XPath expression will be placed on the clipboard ready for use in custom code. The next item that warrants some explanation is the DataSource object. The following class diagram shows how data sources are defined by the InfoPath object model:

Responding to Events in InfoPath Forms

You’ll notice that all of the classes in this diagram are abstract. All data connections are ultimately defined using XML schemas and other XML-based configuration data. At runtime, InfoPath creates objects from these files that derive from the appropriate base class. For example, in our code sample, we declare an object of type AdoQueryConnection to allow us to modify the query for our database connection. In reality, the actual type of this object is AdoQueryConnectionHost, which is an internal type that is created when the connection details are deserialized.

NOTENot all InfoPath forms can make use of managed code due to security restrictions in SharePoint. Custom list template forms and workflow forms that are automatically generated using SharePoint Designer can’t use managed code. When managed code is not available for a particular form type, the Developer tab will not appear in the ribbon. Now that our customer search function works properly, we can publish the form to SharePoint and check out the results.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

Share Point 2010 Topics