Event Handling In InfoPath

Within the InfoPath 2007, there is the option to handle events using an item called the Event Manager. Similar to the event receiver architecture provided by other facilities of SharePoint, the Event Manager provides mechanisms by which forms can provide and respond to event capturing. Writing code that is consumed by the Event Manager is done using Visual Studio Tools for Application (VSTA), and when choosing to program events off the InfoPath design surface it will attempt to open the VSTA IDE.

The Event Manager is called from the InternalStartup() method, which controls the events that are registered when a form is initially loaded. Each event that should be captured can be registered within the InternalStartup() method and then delegates can be constructed to encapsulate a reference to a method which handles the events tripped custom code.

There are several events that can be captured and managed when leveraging the Event Manager.

Event Capturing Available Through the Event Manager

Event Type
Event Capture
Action
Delegate
Control Event OnClick When a user clicks a control in InfoPath ClickedEventHandler(object sender, Microsoft.Office.InfoPath.ClickedEventArgs e)
Form Event OnSaveRequest When a user saves an InfoPath Form SaveEventHandler(object sender, Microsoft.Office.InfoPath.SaveEventArgs e)
Form Event OnContextChange When a user changes a Form Context, such as when a form is submitted SubmitEventHandler(object sender, Microsoft.Office.InfoPath.SubmitEventArgs e)
Form Event OnSign When a user signs an InfoPath form with a digital signature SignEventHandler(object sender, Microsoft.Office.InfoPath.SignEventArgs e)
Form Event OnMergeRequest When a user merges a set of InfoPath forms (merge operation) MergeEventHandler(object sender, Microsoft.Office.InfoPath.MergeEventArgs e)
Form Event OnSwitchView When an InfoPath view is changed (switch view operation) ViewSwitchedEventHandler(object sender, Microsoft.Office.InfoPath.ViewSwitchedEventArgs e)
Xml Event OnBeforeChange Before a passed XPath node is changed, wire an XML event XmlChangedEventHandler(object sender, Microsoft.Office.InfoPath.XmlEventArgs e)
Xml Event OnValidate When an XPath node is being validated, wire an XML event XmlChangingEventHandler(object sender, Microsoft.Office.InfoPath.XmlChangingEventArgs e)
Xml Event OnAfterChange After an XPath node is changed, wire an XML event XmlValidatingEventHandler(object sender, Microsoft.Office.InfoPath.XmlValidatingEventArgs e)
Registering View Delegate in InternalStartup()

Using the InfoPath event handlers is as straight-forward as the event receiver/listener architecture that is present with SharePoint content types and list definitions. The event being captured must be registered within the InternalStartup() method by standard declaration. Wiring an event to display a message box telling the user they are switching views requires registering the event first.

[csharp]

void InternalStartup(object sender, EventArgs e)   
{     
((FormControl)sender).EventManager.FormEvents.ViewSwitched +=        new ViewSwitchedEventHandler(OnSwitchView);    
}
 
[/csharp]
 

View Delegate
Once the handler has been registered within the InternalStartup() method, the event handler that it is called can be declared by a delegate.
 
[csharp]
public delegate void ViewSwitchedEventHandler(object sender,         Microsoft.Office.InfoPath.ViewSwitchedEventArgs e)  
{      
MessageBox.Show(“You are switching InfoPath Views!”);  
}
[/csharp]

With the event wired as such, whenever a user switches InfoPath views, a message box displays, confirming that they are switching views. More elegant event handlers could be developed depending on the event capturing logic that is required; however the overall concept remains the same.

By the same token, it is possible to validate the XML fields so a user entering null values into an InfoPath form is passed a message.

Register Event in InternalStartup()
First, register the XML event handler in the InternalStartup() method. Since it is an XML event, an XPath statement is required in order for InfoPath to know which control to validate against.
 
[csharp]
public void InternalStartup()
{   
EventManager.XmlEvents[“/my:myFields/my:ProSharePoint2007Field “].Validating += new XmlValidatingEventHandler(ProSharePoint2007Field_Validating);
}
[/csharp]
Once the event handler has been registered, the actual event logic can be wired to the event to be called when the XML event is tripped.
Validating a Null Value with Event Handling
Use a String.IsNullOrEmpty if check on the value being passed into the InfoPath control to verify a null entry. Otherwise, you can use the Errors.Add method in order to point each error to the XML node, or InfoPath field the error is associated with; in this case the ProSharePoint2007Field. The other error handling method in the below code is the Error.Delete method which removes the error handler if no errors are encountered in the InfoPath field. Any number of string comparison options that are available through the .NET framework could be leveraged if you’re looking for a more elegant error-checking mechanism.
 
[csharp]

public void ProSharePoint2007Field_Validating(object sender, XmlValidatingEventArgs e)

{  

if (!String.IsNullOrEmpty(e.NewValue))    

{       

Errors.Add(e.Site, “ProSharePoint2007Field “, “Null Values are not allowed!”);    

}   

else    

{       

Errors.Delete(“ProSharePoint2007Field “);    

}

}

[/csharp]

Share

18 New InfoPath Development Articles!

I have finished posting 18 new InfoPath development articles that are available on the main sharepointsecurity.com site for your to browse and learn InfoPath development from, called my “Mastering InfoPath Development Series”. They take you through everything from beginning InfoPath development to building a simple Form WebPart if you don’t have InfoPath available in your environment to use as a design / development tool. I will be extending this series out as I get time, but for those seeking a starting point for InfoPath development, or to maybe pick up some Forms development skills, it should make for some good reading!

If you would like, you can visit the main index of the articles here (note, you will be redirected to the main site using these links):

Mastering InfoPath Development Series Index

Here is the full article index as it appears on the main sharepointsecurity.com site:

InfoPath Development Basics

There are two ways to construct forms for use within a SharePoint environment. The first is to build an InfoPath form and publish it to a SharePoint Form Library. The second is to build a custom WebPart containing the appropriate child controls to collect information from the user and send it into SharePoint via an event handler. Each technique has some advantages and disadvantages, but generally you will find that the InfoPath experience is the easiest and fastest…

Read More


Architecture of InfoPath Forms Services Browser Interaction

InfoPath Forms Services relies on the InfoPath 2007 client application for forms development, VSTO or VSTA to tap into the InfoPath Object Model exposed from Microsoft.Office.InfoPath, and either a standalone OFS 2007 instance or Microsoft Office SharePoint Server 2007 with Enterprise Features enabled to make use of Form Services. InfoPath Forms Services, although offered as a separate product, is directly integrated into the Office Server 2007 platform and even when OFS is a siloed installation will make use of WSSv3 components…

Read More


Introduction To InfoPath Development and The Forms Services Object Model

The administration namespace provides the option to develop routines revolving around common administrative tasks, similar to how the SharePoint administrative namespace exposes classes for managing deployments. The most important class in this namespace is arguably the FormsService class. The FormsService class represents the top level for Forms Service in a web farm. The administration namespace contains various other classes that allow administration operations such as managing form templates…

Read More


Customizing InfoPath Web Service Interaction through Managed Code

One of the most used data connections is a Web Service, and often times the default Web Service connection behavior does not offer the granular level of control that is desired. Since the new InfoPath Object Model is handled through managed code out of the System.Xml namespace, custom web service code can easily be written in order to handle web service consumption on a more granular scale…

Read More


Architecture of the InfoPath Templates (.XSN)

InfoPath templates use several child files and one overlying manifest bundled within an .XSN file. However, there are both packaged and unpackaged InfoPath template states. One of the states is the form template, saved as the bundled .XSN file, which contains all InfoPath source files that although packaged can be extracted using either the InfoPath client or command line operations. Since an .XSN file is basically an archived cabinet file, you can unpackage an .XSN by using the following command…

Read More


InfoPath Form Templates and InfoPath Form Template Parts

When creating a new form in InfoPath, you can create a new template that build out a new packaged .XSN file, or you can build on one of the newer features provided with InfoPath 2007 called a Form Template Part, which instead creates an .XTP file.

Template parts can be loosely compared to User Controls within the Visual Studio IDE. When using template parts, the InfoPath templates that contain controls, datasources, formatting, validation, formatting, rules, and calculations can be reused over and over again without having to keep performing the same redundant tasks…

Read More


Working With InfoPath Controls on the Design Surface and Building a Basic InfoPath Form

he InfoPath design surface provides many methods to build and enhance an InfoPath form with custom actions such as conditional formatting, rules, and other formidable functionality. There are several options available from the control level menu that a developer can leverage to circumvent having to write custom code to achieve certain form tasks. We have already explored how to use a template part in order to build a reusable InfoPath form piece similar to user controls in Visual Studio development that can be dragged onto the InfoPath design surface…

Read More


Managing Data Connections and Universal Data Connection V2 (UDC) Files

InfoPath exposes several external data sources that are available for consumption either as a primary or secondary data connection. Most of the consumed data connections can be called from within the Data Connection Wizard that InfoPath provides. When using the Data Connection Wizard, you can choose to create a new data source for fetching or submitting. In relation to SharePoint, it is possible to crawl a Microsoft Office Server instance to harvest available data connections, by only supplying the site…

Read More


The XmlFormView Control

The XmlFormView control plays the central role in rendering the display to a user in an HTML compatible format. When not using the Forms Service XmlFormControl within a WebPart, it becomes exceptionally difficult to develop a custom solution to render out the InfoPath form. It could be theorized that one could load the InfoPath XML document by calling a StreamReader on the XML contents, go through all the XML contents…

Read More


Event Handling In InfoPath

Within the InfoPath 2007, there is the option to handle events using an item called the Event Manager. Similar to the event receiver architecture provided by other facilities of SharePoint, the Event Manager provides mechanisms by which forms can provide and respond to event capturing. Writing code that is consumed by the Event Manager is done using Visual Studio Tools for Application (VSTA), and when choosing to program events off the InfoPath design surface it will attempt to open the VSTA IDE…

Read More


Deployment Scenarios and Forms Service Security

Deploying an InfoPath form involves examining the type of InfoPath development that was performed, whether the forms you developed were codeless or code-bound. When developing custom forms that don’t hook into any backend business logic, the forms can simply be deployed to the server by an end user for consumption by other organizational units. However, if the .XSN contains backend business logic, a server administrator must intervene in the deployment process in order to deploy the form, providing the vital step of allowing activation of the form before the form is consumed by the user base. Server administrator intervention is also required when other conditions for form deployment are met, namely if the form being deployed requires full-trust…

Read More


Building Forms without Forms Services – Introduction

For some organizations, it is not possible to use Forms Services either as an architectural or budget constraint. Therefore, other avenues of development must be considered when looking to move to a paperless form process with zero footprint form fill-in capabilities. When not using InfoPath and Microsoft Office Forms server, a traditional solution is to build forms using standard WebPart development techniques, submitting the data to either a corporate database or to a SharePoint list for storage…

Read More


Building Forms without Forms Services – Part 1 – Set Up the WebPart Class

Before accomplishing any custom development, the necessary foundational code must be added to the WebPart in order to set it up for inclusion in the SharePoint environment. You must establish the following references (shown in the code listing) in the main WebPartclass file. Doing so allows WebPart class derivation out of the WebPart base class, procures SQL connectivity using ADO.NET 2.0, allows for definition of WebPart attributes, and tolerates the binding of the appropriate user interface controls for final output by an overridden RenderWebPart method…

Read More


Building Forms without Forms Services – Part 2 – Declare Variables, Assign Controls, And Set up Exception Management

Once the class is setup for the Form WebPart, you need to declare relevant variables and instantiate the required controls by overriding the CreateChildControls() method. For the Forms WebPart, which only accepts an ID input, the only required controls are a TextBox control and a new button that is wired to a submission event…

Read More


Building Forms without Forms Services – Part 3 – Setup the Connection to the SQL Server with ADO.NET 2.0

In order to manage the connection to the database and perform relevant database operations, use ADO.NET functionality out of the System.Data.SqlClient namespace. For the Forms WebPart, ADO.NET provides the crux of the operations for database logic.

In order to open a connection to the SQL database, the Forms WebPart can harvest the connection information out of a configuration file by using WebConfigurationManager out of the System.Web.Configuration namespace. By exposing the AppSettings public property, you can return key-value pairs from the configuration file…

Read More


Building Forms without Forms Services – Part 4 -Setup the Validation Controls

The data that is being submitted with the Forms WebPart requires validation before it is committed to the database in order to maintain integrity of the information being stored. Doing validation with WebParts typically occurs in two main ways. One can choose to script a separate method in order to validate the entry by using an option like ServerValidateEventArgs.IsValid against the argument, or the inherent validation controls that ASP.NET 2.0 provides can be called in order to validate the information. Considering software architecture concerns and code bloat as a factor, it is typically preferable to use the inherent ASP.NET 2.0 validation options…

Read More


Building Forms without Forms Services – Part 5 – Wiring The Submission Event

The last portion required for the Form WebPart is getting the actual data into the database by wiring a submission event to the save button declared previously, easily accomplished by calling a stored procedure to accomplish the task. By pursing the option of using stored procedures, the option exists whether to use the native CLR stored procedures or to use a standard T-SQL stored procedures.

Since the submission of the data is relatively straightforward, the Forms WebPart uses three small classes to build extendable business logic…

Read More


Conclusions On Forms Services Development

Using InfoPath 2007 and InfoPath Forms Services within a SharePoint environment is a powerful option to take legacy paper-based form processes and convert them to powerful electronic data entry mechanisms that streamline overall business process while easing overall development efforts. Although there are methods to generate forms for use within SharePoint by developing custom WebParts that contain the relevant .NET controls for data capture and event handling to fetch or submit data to a variety of a data sources, the inherent InfoPath development capabilities make it a lucrative option for form development tasks…

Read More


Share