Applies To: Microsoft Office InfoPath 2003 SP-1 Preview
InfoPath SP-1 introduces a number of exciting new built-in controls. One of which is the Master/Detail control. After InfoPath 2003 was released, one of the most common questions on the InfoPath newsgroups was how to implement a Master/Detail type of control in InfoPath. Although this was possible in InfoPath 2003 prior to SP-1, doing so was not easy or straightforward. For this reason, InfoPath 2003 SP-1 now includes built-in support for the Master/Detail control.
The Master/Detail control allows you to designate one control as a master that drives the data in another control which is called the detail. When the user selects an item in the master, the corresponding data in the detail is displayed.
When designing a form template in InfoPath design mode, inserting a Master/Detail control into your form is easy. There are actually two ways to do so. The first way is to use the Master/Detail control in the Controls toolbox. Inserting the Master/Detail control from the Controls toolbox actually inserts two controls – a Repeating Table that is designated as the master and a Repeating Section that is designated as the detail. When you insert the Master/Detail control this way, as long as the “Automatically create data source” checkbox in the Control toolbox is checked, a simple data structure is created in the data source. This structure consists of a group node containing one repeating group node that, in turn, contains four child fields. The master and detail are both bound to the inner repeating group node. In this case, the master and detail are said to be linked by position in the tree. This basically means that if you select the third item in the master control, for example, the data for the third item is displayed in the detail control. This enables you, for example, to build a form that contains basic customer information, such as customer name and SSN, in the master and more detailed information about that customer such as address and phone number, in the detail.
The second way to create a Master/Detail relationship is by manually specifying which control is the master and which is the detail. Although this is a bit more difficult than choosing the Master/Detail control from the Controls toolbox it does give you more control over how the master is linked to the detail. (As mentioned earlier, one way of linking a master control to a detail control is by position. The second way to link a master to a detail is by key field. This type of linking allows you to specify a primary key/foreign key type of relationship where the value of the primary key in the master determines which detail data is displayed. This type of linking is only available when creating a Master/Detail relationship manually.)
To create a Master/Detail relationship manually, perform the following steps:
Now, when you use your form, you will notice that when you select an item in the master, only those detail items whose detail key matches the master key of the currently selected item in the master control will be displayed.
Obviously, if there is no data, no details will be displayed. InfoPath provides a nice way to deal with this situation. When walking through the steps to manually create as Master/Detail relationship above, you may have noticed the option “Copy key field from selected master when inserting detail” which is checked by default. This option designates that when inserting a new detail item, the value of the master key of the item that is currently selected in the master control will be automatically copied to the detail key in the new detail item. This is quite convenient when creating Master/Detail data from scratch.
As you can see, creating a Master/Detail relationship in InfoPath 2003 SP-1 is very easy and is just one of the many new features that were added in direct response to customer feedback.
While InfoPath does not include a multi-select list box control, it is possible to create one using the controls present in InfoPath SP1 Preview:
Like all form design decisions in InfoPath, the first thing you need to do is think about the data you want to collect – how do you want the multiple selections represented in the XML saved or submitted by the InfoPath form? Additionally, do you want the selections to be determined at form design time (static), or at runtime (dynamic)?
Here’s one approach that allows either a static or dynamic list of choices by including the choices – and the selection state – right in the form data.
First, create a data structure as follows:
Here are the steps to do this:
Note that if you want a very different data structure the rest of these instructions won’t apply directly, but they should get you started down the right path in terms of understanding how to create a complex control out of the primitives that InfoPath provides.
Now you need to build the view – here’s what I came up with, showing the design-time structure:
This is a Scrolling Region as the outer container for the control, containing a Repeating Table for the options, with a Check Box and Expression Box for each option. Here’s how you make it:
Next, tweak the layout and borders to make it look professional:
Finally, if you want to make the selected options stand out clearly, you can use Conditional Formatting:
At this point, the Multi-Select List Box control is ready to go – but it doesn’t have any options! Maybe those options are specified by your form’s back end data source (a database or web service). But for now, let’s assume the list is static:
That’s it! Now just hit the Preview button on the toolbar to try our your new Multi-Select List Box control.
Note: You can also create ActiveX controls that do XML data binding with the InfoPath SP1 Preview.
Want to export your InfoPath form view to a Microsoft Office Word document?
The easiest way to do this is to export your InfoPath form to an MHT file using File | Export To | Web... while filling out your form. Then, just open the MHT file in Microsoft Office Word. The Word document that you create based on the MHT file exported from InfoPath will look very similar to the InfoPath form itself.
To enable this feature, you must first apply a language pack. To do this, go to Start -> All Programs -> Microsoft Office -> Microsoft Office Tools -> Microsoft Office 2003 Language Settings
In the list of Available Languages, select "Akkadian"
Click Add >> and then Click OK. You will need to restart InfoPath.
This will also install all the files needed for the Voynich, Vinca, Iberic, Etruscan, Linear A (Minoan form), Linear B (Greek form), and Rongo Rongo language support. Please be aware that the default currency will be switched to zuzu and the default date format will be synodic.
Cuneiform support is especially powerful when combined with Microsoft's Tablet platform.
(Picture of the InfoPath editor in Akkadian)
InfoPath’s custom control support allows users to create controls for three different types of binding:
Simple data type (string, numbers, etc)
Controls that are written to bind to simple data types would allow a control to do custom processing on data before it gets put into the XML. The control can be designed to have UI that combines multiple simple controls (buttons, textboxes, checkboxes, etc…) to encapsulate them into one control. For example, multiple buttons can be combined with a textbox to make an in-document calculator control. Combining these all into one control will provide a simple way to re-use the same control in multiple forms.
InfoPath SP-1 allows XML nodes to follow any schema. This allows form developers to work with industry standard XML Schemas. One example is a MathML control that could be written for InfoPath to save XML compliant with the MathML schema and display it in InfoPath form in a meaningful manner.
For greater flexibility, InfoPath custom controls can be bound to an IXMLDomNode and any msxml operations can be performed directly on the XML tree.
Custom controls need not be installed on every form users’ computer before loading the form. Controls can be packaged with your form solution so that on first open, the control will be registered and installed. Controls should be stored in a CAB files and able to self-register.
Custom controls in InfoPath have a few security constraints to keep users safe. Firstly, all custom controls used within InfoPath require the IObjectSafety interface to be implemented and the control to be marked as Safe for Scripting and Safe for Initialization. Without these two flags, InfoPath will not load the form and will notify the user.
In addition, for solution which have controls packaged in the form solution, it is necessary to sign the CAB files with a digital signature. When users open the form for the first time, they will be prompted on whether or not they will accept the control signed with that signature (similar to the ActiveX control dialogs you see in Windows 2k/XP).
For detailed information on how to write a custom control for InfoPath, see Lab 06 in the MSDN InfoPath 2003 Training. (http://msdn.microsoft.com/library/en-us/odc_ip2003_tr/html/odc_INF_Lab_06.asp)
The final version of InfoPath Hands-on Labs has been posted on MSDN. The labs provide an overview of InfoPath 2003 and SP1 features, and are divided into the following topics:
All practice files and setup instructions are included with the labs. The labs require InfoPath 2003 Service Pack-1 Preview which can be downloaded from here.
InfoPath supports two methods on the View OM object - "SelectText" for data entry controls and "SelectNodes" for structural controls - in order to enable programmatic selection.
Data entry controls that can be programmatically selected (using View.SelectText):
Structural controls that can be programmatically selected (using View.SelectNodes):
Programmatically setting focus to these controls is not supported:
Steps to select rows in a repeating table using SelectNodes:
In order to set selection extending the 1st two rows of a repeating table you can do the following steps:
1. Insert a "repeating table" from the controls task pane
2. Insert a "button" from the controls task pane
3. Double click on the button control to bring up Button Properties
4. Click on the "Edit Form Code" button
[you may be asked to install Microsoft Script Editor if you don't already have it installed]
5. This should bring up script.js file in Microsoft Script Editor with a function such as
// Write your code here
6. Insert the following code inside the above function
var nodeSelStart = XDocument.DOM.selectSingleNode("/my:myFields/my:group1/my:group2")
var nodeSelEnd = XDocument.DOM.selectSingleNode("/my:myFields/my:group1/my:group2")
[This assumes that the repeating table is bound to my:group2. You can figure the XPath by looking at the Data Source task pane after selecting the appropriate repeating table.]
7. Now you should be able to preview the form and verify that clicking on the button causes the expected selection. Please note that you have to have at least two rows in the table in order to select the first two rows. Otherwise you will see an error.
Steps to select text in a text box using SelectText:
In order to select text in a text box you can do the following steps:
1. Insert a "text box" from the controls task pane
var nodeSelText = XDocument.DOM.selectSingleNode("/my:myFields/my:field1")
[This assumes that the text box is bound to my:field1. You can figure the XPath by looking at the Data Source task pane after selecting the appropriate text box.]
7. Now you should be able to preview the form and verify that clicking on the button causes the expected selection.
While the InfoPath 2003 SP-1 object model is quite extensive, it doesn’t provide all the functionality that is exposed through the InfoPath menus and toolbars. However, you are not limited by that fact. Using the CommandBars object, you can access any of the functionality available in menus and toolbars.
For example, the InfoPath object model exposes a Print method but not a PrintPreview method. However, that doesn’t mean that you can’t access this functionality. Using the CommandBars object, you can execute the Print Preview functionality available on the Standard toolbar like so:
The list of available command bars is on the View | Toolbars menu. If you want to access a menu item, use “Menu Bar” for the command bar name. The control name to use is the same name that appears on a menu or in the tooltip when the mouse is hovered over a toolbar button. (Please refer to MSDN (http://msdn.microsoft.com) for more information about the CommandBars object.)
In the InfoPath Service Pack 1 release, it is now possible for form templates to be opened from locations other than their published location. There is also a ‘Send Form as Attachment’ option under the File menu which attaches your form template to an Outlook mail message for distribution. However, for security reasons, there are still limitations on what kinds of form templates can be opened and from what locations. The following is a guide to understanding the InfoPath SP1 Deployment and Security Model:
Form Template Security Level
Each Form Template made in InfoPath SP1 has one of three security levels specified; Restricted, Domain, or Full Trust. This setting is determined automatically by default, but can be set manually, if desired.
NOTE: To access this setting in the Designer, navigate to Tools | Form Options à Security Tab.
Restricted – The form template does not allow any access outside of the form
Domain – The form template allows access outside of the form, but only within the domain of the form template
Full Trust – The form template can access files and settings on the local computer
The Full Trust security level can only be set manually by the user for installed templates or certificate-signed templates. The maximum trust level that can be set automatically by InfoPath is Domain.
All new blank form templates (except for Managed Code solutions) start out at the Restricted security level. As you build the form, adding any of the following will automatically raise the security level to Domain:
Opening the Form Templates in the InfoPath SP1 Editor
The reason to make a distinction between Restricted and Domain security was to allow for form templates without script or data connections to be opened from anywhere. Therefore, email deployment of restricted form templates in SP1 is easy, just send out the form template and it can be opened either from the Outlook mail itself or from wherever the recipient saves it.
With Domain form templates, some of the same security restrictions from v1 still exist, but SP1 allows for some added functionality. Domain form templates still require that they be opened from their published location. However, by using the Send Form as Attachment option in the file menu, a Domain form template can be mailed out as an attachment. This attachment, when received and opened, functions as a link to the actual published location. The form template at that publish location is what actually gets opened in the InfoPath Editor, not the one that was clicked on. At that point as well, the published form template is copied locally and will appear as a selection in the Fill Out a Form dialog every time you launch InfoPath.
This posting is meant as an introduction and does not cover all aspects of Deployment and Security. If there are any specific questions, please respond via feedback to this article and I will follow up with further entries that will address more specific functionalities and scenarios.
InfoPath provides two controls which saves pictures inside the XML form (rather than linking to it). When trying to process this XML file outside of InfoPath, you will need to translate the data back into the image binary. InfoPath picture control data and ink picture control data is stored in the XML as base64 encoded data. You will need to decode the base64 picture into binary before it is usable.
Below is a code sample in C# that will do it:
byte image = Convert.FromBase64String( s );MemoryStream memStr = new MemoryStream();memStr.Write( image, 0, image.Length );Image img = Image.FromStream( memStr );img.Save( filename );
InfoPath has a really powerful feature to allow users to create their own custom controls for InfoPath forms using Microsoft's ActiveX technology. One requirement that is essential for controls to work as expected in InfoPath is that the controls must fire OnPropertyChange Notifications so that InfoPath knows to grab the information and copy it into the XML DOM. The unfortunate thing is that there are some already built controls which don't fire OnPropertyChange Notifications but they would be incredibly useful in an InfoPath form.
Here's what to do if you want to use these types of controls. InfoPath will grab the value before you save, so if you don't need other parts of the form to interact with the data from the ActiveX control, then you don't really need to do anything. Your data from the ActiveX control will always get saved.
If you do need to pull data from the ActiveX control before it is saved (maybe for example on a OnAfterChange or a button click), you should call XDocument.ForceUpdate(); before grabbing the value. This will cause InfoPath to query the ActiveX control for the value and place it into the XML DOM so then your business logic will be able to get the correct value.
When writing script in the Microsoft Script Editor (MSE), you can quickly locate help on the InfoPath Object Model by positioning the cursor on a keyword (object, method, property) and hitting F1. This can save browsing through help.
(We weren't able to hook up IntelliSense in MSE, so knowing this F1 trick is a big help when doing VBScript or JScript development with InfoPath. If you download the InfoPath 2003 Service Pack 1 (SP1) Preview and try out the InfoPath 2003 Toolkit for Visual Studio .NET you'll find full IntelliSense integration when writing managed code for InfoPath projects.)