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:
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.
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.
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:
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.
Share Point 2010 Related Interview Questions
|Web Services Interview Questions||XML Interview Questions|
|Share Point 2010 Interview Questions||ASP.NET Interview Questions|
|Share Point Administration Interview Questions||BizTalk Admin Interview Questions|
|Microsoft Office SharePoint Server (MOSS) Interview Questions||Biztalk Server Interview Questions|
|Asp Dot Net Mvc 4 Interview Questions||Biztalk Esb Toolkit Interview Questions|
|InfoPath Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.