December 2009 - Posts - Mel Balsamo

InfoPath Dev

This Blog


Mel Balsamo

December 2009 - Posts

  • Qdabra's Header-Footer Template Part

    When creating InfoPath solutions, one of the most important aspects is the visual design. This includes making sure that the layout, fonts, colors, white spaces, and most especially, the branding, are all uniform. We can always decide how our forms look like, but for a company to have its unique identity in its InfoPath forms, it should maintain proper branding by using its own company logo.

    Company logos can either be placed in the InfoPath form’s header or footer, or both. Qdabra created a template part that has header and footer sections built-in. We can just change the logo, form title, company details, etc. and start using them in our forms.

    Here’s how the Header-Footer XTP looks:


    This blog post details the steps needed to modify the Header-Footer XTP and begin using it in your InfoPath forms.


    • Header-Footer XTP – Download it FREE here and save it your local machine.
    • InfoPath 2007 – template parts (XTPs) are not supported in InfoPath 2003.


    1. Launch InfoPath.

    2. In the Getting Started dialog, under the ‘Design a form section’, click Design a Form Template…


    3. In the ‘Open a form template’ section, click On My Computer…


    4. In the ‘Open in Design Mode’ dialog box, select InfoPath Template Parts (*.xtp) from the file types dropdown.


    5. Browse to the location where you saved the Header-Footer XTP and open it.

    6. The template part will open in InfoPath Design mode.


    7. Make all the necessary changes:

    a. Header: replace the company logo with your own.

    b. Footer: replace the small logo/icon as well as the company details.

    Note: The Document ID in the footer is applicable only if you have Qdabra DBXL installed. You can delete this whole row if you do not intend to use the form with DBXL.

    8. Save and close the template part.


    1. Launch InfoPath and select Design a Form Template based on a new blank one.

    2. In the Controls taskpane, click Add or Remove Custom Controls…


    3. In the Custom Controls dialog box, click Add > Template Part, and browse to the location where you saved your HeaderFooter XTP.


    4. Verify that the XTP has been added to your Custom Controls taskpane.



    1. In your blank InfoPath form template, click or drag the the HeaderFooter XTP from the Custom Controls taskpane. This will add the XTP onto your view.

    2. Highlight or select the entire contents of the HeaderFooter XTP section.


    3. Drag the selection outside the section.


    4. Delete the empty HeaderFooterXTP section, leaving only the its dragged contents in the view.


    5. Delete the HeaderFooterXTP node from the main data source.


    6. Modify the two expression boxes in for the Document ID found in the footer.

    Note: You may skip these steps and proceed to Step 7 if you do not intend to use the form with Qdabra DBXL.

    a. Change the conditional formatting for the expression box labeled New.

    i. Right-click on the expression box and select Conditional Formatting


    ii. In the ‘Conditional Formatting’ window, click Modify.

    iii. Delete my:HeaderFooterXTP in the formula.


    iv. Click OK twice to close the dialogs.

    b. Change the formula for the Document ID expression box.

    i. Right-click on the expression box and select Expression Box Properties…


    i. In the ‘Expression Box Properties’ window, under the ‘General’ tab, click on the fx button.

    ii. Check ‘Edit XPath’ in the Formula dialog and delete my:HeaderFooterXTP


    iii. Click OK twice to close the dialog boxes.

    iv. Repeat all the steps in 6a above but this time, changing the conditional formatting for the blank Document ID expression box.

    7. Change the formula for the Form Version expression box in the footer.

    a. Right-click on the expression box and select Expression Box Properties…

    b. In the ‘Expression Box Properties’ window, under the ‘General’ tab, click on the fx button.

    c. Check ‘Edit XPath’ in the Formula dialog and delete my:HeaderFooterXTP


    d. Click OK twice to close the dialog boxes.

    That’s it! You can now design your form to suit your company needs. By having all your forms designed this way, ensure that you are maintaining uniformity and proper branding in your InfoPath solutions.

  • Qdabra's Zero-ActiveX Contact Selector XTP


    You want to use the InfoPath Contact Selector to add multiple contacts to your form, but:

    • Selecting multiple users with Contact Selector requires code
    • Contact Selector is an ActiveX control and requires installation on client machines
    • Contact Selector doesn’t work for browser-based forms when the user is not using Internet Explorer


    Install Qdabra’s Zero-ActiveX Contact Selector

    • Based on Qdabra’s qRules library – extend your InfoPath forms without writing code
    • Easy-to-add XML Template Part – just add custom control via the InfoPath 2007 Designer
    • Comes with pre-configured layout which saves you time – just drag and drop from the taskpane
    • No ActiveX – works with browser based forms


    Let’s take a quick look: here is a screenshot of Qdabra’s Zero-ActiveX Contact Selector XTP


    In the screenshot, the user searched for all users with “admin” in their Active Directory records and then clicked on the arrows to add Jim Cantwell and Patrick Halstead to the form.

    This blog post details the steps needed before you begin using the XTP in your InfoPath forms; just a few modifications and tweaks and you’re ready to go!


    • QdContactSelectorXTP – Contact Selector template part, no ActiveX required, no code.
    • InfoPath 2007 – template parts (XTPs) are not supported in InfoPath 2003.
    • Qdabra Database Accelerator – includes the Active Directory Web Service. Download a FREE trial here. Alternatively, you may purchase Qdabra’s Active Directory Standalone tool here.
    • Qdabra qRules  – add the most commonly requested InfoPath features without the need of writing code. Download a FREE trial here.
    • Admin-deploy to SharePoint – qRules is a library that contains code, so when you publish your form to SharePoint you need to publish it as an administrator approved form. This requirement goes away for SharePoint 2010.


    1. Launch InfoPath and select Design a Form Template based on a new blank one.

    2. In the Controls taskpane, click Add or Remove Custom Controls…


    3. In the Custom Controls dialog box, click Add > Template Part, and browse to the location where you placed your QdContactSelector XTP.


    4. Verify that the XTP has been added to your Custom Controls taskpane.


    5. Save your form template (XSN). For the purposes of this blog post, we will name it as ContactSelectorXSN.

    6. Close InfoPath.


    1. Launch the qRules Injector from Start > All Programs > Qdabra > Tools > qRules Injector.


    2. Browse to the location where you saved your ContactSelectorXSN.

    3. Click Inject, then OK in the confirmation dialog, and then close the qRules Injector.

    4. Open ContactSelectorXSN in InfoPath Design mode.

    5. Scroll down to the very bottom of the Controls taskpane to get to the Custom section, and then click on the QdContactSelector control.

    You should now have the template part on your canvas. The main and the secondary data sources will be injected in your XSN as well.



    If you go to Tools > Data Connections, you will notice that you have two instances of QdabraRules, one for the XSN, and one for the XTP:


    When you first injected qRules in your XSN, it added the QdabraRules XML as a secondary data source. In this same XSN, you injected the QdContactSelector XTP which also uses qRules. This added another QdabraRules XML secondary data source to the XSN (with a different name). So now, you have two qRules XMLs, which is confusing and might cause issues when calling the qRules commands, hence the need to do some clean-up.

    1. Save ContactSelectorXSN as source files and close InfoPath.

    2. Modify the manifest.xsf file:

    a. In the directory where you saved your source files, locate manifest.xsf and open it in any text editor.

    b. Replace all seven instances of “QdabraRules_QdContactSelector” with “QdabraRules”.

    c. Delete the associated blocks where you find “QdabraRules1”:

    i. xsf:file (for .xsd)


    ii. xsf:file (for .xml)


    iii. xsf:dataObject


    d. Save and close manifest.xsf.

    3. Modify the sampledata.xml file

    a. Open sampledata.xml in a text editor.

    b. Delete the xd:DataConnection block where you find “QdabraRules_QdContactSelector”.


    c. Save and close sampledata.xml.

    4. Delete the extraneous QdabraRules1 files in the source files directory:

    a. QdabraRules1.xml

    b. QdabraRules1.xsd

    5. Verify changes.

    a. Open manifest.xsf in InfoPath Design mode.

    b. Go to Tools > Data Connections and verify that you now have only one instance of QdabraRules.



    1. In Tools > Data Connections, modify the FindUsersByName_QdContactSelector data connection.

    2. Replace servername (in http://servername/qdabrawebservice/ADUserInfo.asmx?WSDL) with the correct location where you installed DBXL.


    Note: If you are using Qdabra’s AD Standalone Tool, the AD Web Service URL should be in the format: http://servername/QdabraAD/ADUserInfo.asmx?WSDL.

    3. Click Next and make sure that the FindUsersByName operation is selected. Click Next again.

    4. Leave the tns:name parameter blank, and for the tns:searchType*, select Contains.


    5. Click Next twice more, then Finish to exit out of the wizard.


    Since you’ve added the QdContactSelector XTP into an XSN, you need to make sure that the qRules commands point to the new fields’ XPaths.

    1. Double-click on the  button to open its properties.


    2. Click Rules and modify all the three actions in the Insert User rule:


    a. Change the first action that calls the Insert command to:

    Insert /parent=/my:myFields/my:UserList /child=/my:Alias /count=1


    b. Change the second action that calls the SetValue command to:

    concat("SetValue /xpath=/my:myFields/my:UserList/my:Alias[last()] /value=", @value)


    Note: @value refers to a field in the form. If in doubt, tick the checkbox labeled Edit XPath to see the full xpath of the @value node.

    c. Do the same for the third action for the SetValue command:

    concat("SetValue /xpath=/my:myFields/my:UserList/my:Alias[last()]/@my:name /value=", @display)


    3. Click OK as many times needed to close all the dialog boxes.

    4. Double-click on the  button to open its properties and modify the Remove User rule.


    In the Insert Formula dialog, check on the Edit XPath (advanced) box and change the Delete command to:

    concat("Delete /xpath=/my:myFields/my:UserList/my:Alias[", count(preceding-sibling::my:Alias) + 1, "]")


    5. Click OK until all dialog boxes are closed.

    6. Add conditional formatting so that, when users have already selected a contact, they can no longer add the same contact.

    a. Double-click on the  button to open its properties.

    b. Go to the Display tab > Conditional Formatting > Add.

    c. Add a condition such that if Alias (from the main data source):


    is equal to the value node (from the FindUsersByName_QdContactSelector secondary data source):


    then hide the control:


    d. Click OK until all the dialog boxes are closed.

    e. Do the same for the @display field. Double-click on the textbox to open its properties.


    f. Go to the Display tab > Conditional Formatting > Add.

    g. Add a condition such that if Alias (from the main data source) is equal to the value node (from the FindUsersByName_QdContactSelector secondary data source), then change the font color to something lighter:


    h. Click OK until all the dialog boxes are closed.

    That’s it! You’re all set to use Qdabra’s Zero-ActiveX Contact Selector! Test your XSN in Preview mode and search for users, select contacts and even delete them. Finish designing your form template, save it, and you’re ready to go!


    Here’s a link to an article describing how to publish your new form to SharePoint so you can use it in the browser.

    You can also refer to the User Guide that comes with your qRules v2.0 installation for instructions on how to use your qRules solutions in InfoPath Forms Services.

  • Copy SharePoint List Data to Main Data Source

    This post was originally written by Clay Cobb and is republished here with permission. To see the original article, please click here.

    One thing that you can't easily do in InfoPath is to copy repeating data from a secondary data source - like a SharePoint list - to the main data source. This is an important necessity, because the data from secondary data connections does not get saved in the resulting XML data file of a submitted/saved InfoPath form. So, when you look at the form initially, you see the nice pretty data from your SharePoint list enumerated within the repeating table you placed on the canvas, but if you were to open the raw XML file, none of that data would be there. This is because an InfoPath form only keeps whatever data is saved to its main data source. A data connection to a SharePoint list is just a secondary data connection, which in essence becomes a window into the data as it currently exists. Yes, you can re-open your XML file in InfoPath and see the data from your SharePoint list, but it's the current instance of that data, not the data that existed at the time you previously submitted the form. Sometimes, this is ok, but what if you needed to get that SharePoint data into your form and keep it there? To do this, you must copy the data into the main data source. How can you do that? Well, you can custom code something, or you can use the great set of special commands known as qRules that is provided to all of us by Qdabra. qRules allows you to do many things, but the one command we will focus on is named CopyTable.


    • qRules introduces code to your form, so if your forms are browser-enabled, then they will require Full Trust and Administrative-Approval publishing type. I have not tested any in browser forms yet
    • The CopyTable command will only work if the nodes match, which also means each node has to have data in it (no blank fields). The reason your fields can’t be blank is because when there is a blank field, no placeholder for that field is brought down in the XML, so it’s as if that node doesn’t exist.

    The example I will use for this blog is a Weekly Status form template (based off the Meeting Agenda sample) within a Meeting Workspace where you pull in Active Tasks from a SharePoint Task List on demand so that a snapshot of the tasks is saved within the form. The purpose of this is so that at a later time, the Weekly Status for that week's meeting can be opened, and you will see the status of the team's tasks when the meeting occurred rather than the current point in time. In essence, it becomes an historical record of the team's tasks just like meeting minutes are intended to be. For the purposes of this blog, I will not go into great detail about meeting workspaces and how they work, but I will briefly explain how InfoPath forms need to be used in order to get the recurring meeting functionality. Here are the steps to accomplish the goal:

    1. Create Tasks List (covered in minimal detail)
    2. Create Meeting Workspace with a Form Library (covered in minimal detail)
    3. Create Form Template
    4. Install qRules and Inject Form
    5. Apply CopyTable Command Rule
    6. Publish the Form and Verify Success

    Create Tasks List

    • Create a simple tasks list.
    • Add some tasks with a variety of statuses, priorities, and due dates (Fig 1).


    Fig 1 - Basic tasks list with several tasks added

    • Take note that the Active Tasks built-in view only shows tasks that are not completed (Fig 2).


    Fig 2 - Active Tasks view only shows incomplete tasks

    • Set Active Tasks view as Default View.

    Create Meeting Workspace

    • Create a Basic Meeting Workspace with Recurrence (I prefer to use Outlook 2007 to create my recurring meeting, and then I use the integrated Meeting Workspace feature button to provision my site in SharePoint - Fig 3).


    Fig 3 - Creation of Meeting Workspace in Outlook 2007

    • Edit the default page of your new Meeting Workspace and close the default web parts (unless you prefer to use one or many later).
    • Create Form Library and be sure to NOT click Yes for "Change items into series items" (Fig 4). If we do that, then all forms show on every meeting page (each recurring date). If we leave this as No, then only the relevant form for that meeting will display each week.


    Fig 4 - Form library within a Meeting Workspace - not a series item

    • This will put your new Weekly Status form library on the default page for each recurring meeting within this workspace (Fig 5).


    Fig 5 - View of default Meeting Workspace page showing the current week

    Create Form Template

    • Create new template based on built-in sample Meeting Agenda template and modify to your preference (Fig 6).


    Fig 6 - Weekly Status form template

    • Create a Receive data connection to the Team Tasks SharePoint list, but set it NOT to "Automatically retrieve data when form is opened" (Fig 7). Be sure to choose only the fields you want to ultimately see in the form, because this will play a big part in our CopyTable command.


    Fig 7 - Tasks data connection with automatic retrieval check box de-selected

    • Create data structure in form template that exactly matches the data structure of the SharePoint data connection. Your SharePoint Tasks list data connection will include whatever fields you selected during the creation of the data connection from step 2. Simply go to the Data Source pain in InfoPath and choose your "Tasks (Secondary)" data source. Drill down until you get to the nodes. You will notice that the fields within the Tasks repeating group are attributes and not elements (this is important). *Note: You can also see the raw data structure by clicking Save As Source Files and opening your Tasks.xsd file in notepad. Now, go back to your main data source and add a new non-repeating group (aka Table) that includes the Tasks repeating group (aka Row) and all the attribute fields (Columns). Be sure that the field names and data types match exactly for the attribute fields (Fig 8 ).


    Fig 8 - Tasks node structure in main data source matching SharePoint secondary data source

    • Drag repeating Tasks group from Main data source onto the canvas as a repeating table and configure the columns/fields (Fig 9).
      • Stretch and shrink the columns so that the data will display properly
      • Change the Complete column header to %
      • Change the % field control format to show Percentage with ndecimal places
      • Change the Due Date field control to a Date Picker (optional)
      • You'll also probably want all of these to be read-only fields. *Note: To make a Date Picker control Read-Only, you set conditional formatting on it that says, “If Due_Date is present, then make control Read-Only."


    Fig 9 - Tasks Main data source repeating table with formatting

    Install qRules and Inject Form

    • After installing qRules, you will see that it does far more than CopyTable, but those other commands will be the subject of future blogs. You can also get previously-written explanations and discussions related to qRules here.
    • After a successful install, Inject qRules into the form template (Fig 10)


    Fig 10 - Injecting form template with qRules

    Apply CopyTable Command Rule

    • Create button for retrieving Active Tasks on demand and for performing the CopyTable qRules (Fig 11)
      • Simply drag a Button to the canvas and change the label to something like Show Active Tasks
      • Click the Rules button and Add a rule named something like Query Tasks and Copy
      • Add an Action that Queries using the Tasks data connection
      • Add an Action that Set's a Field's Value, choose the Command node from the QdabraRules (Secondary) data source, and set the value to this command string:
        CopyTable /dsnamesrc=Tasks /tablesrc=/dfs:myFields/dfs:dataFields /rowsrc=dfs:Tasks
        /tabledest=my:meetingAgenda/my:Task /rowdest=my:Tasks /empty=yes
        • KEY NOTE!! Do not try to paste your command string into the function builder (fx button). Just paste it directly into the Value field.
        • dsnamesrc: This is the name of your source data connection, which is named Tasks in our example. Remember that this could be different if you apply this elsewhere, so be sure to use the proper name for this attribute
        • tablesrc: This is the table within your data source that provides the data. You need to properly type in the hierarchy from the Tasks secondary data connection using the information you found in Figure 8. Notice that the namespace for a SharePoint list is DFS and not MY.
        • rowsrc: This is the repeating group that includes the nodes from your SharePoint data connection. Mine is Team_Tasks, but if you use the default Tasks list from a Team Site, this would just be dfs:Tasks.
        • dsnamedest: This is not shown, because it defaults to the main data source, but if you needed to copy your data to another secondary data source, you would provide the name of that data connection here.
        • tabledest: Like tablesrc, this is the table that will receive the data. This uses the structure we created in our main data source in Figure 8. Notice the default namespace for an InfoPath form is MY, and then my data source root is meetingAgenda due to using the Meeting Agenda sample template.
        • rowdest: This is the repeating group where we want to send the data
        • empty: This is a field that accepts a yes/no flag based on whether you want to first erase all existing data first from the destination table or not.


    Fig 11 - Custom button that queries the SharePoint list and performs the CopyTable command

    • Preview the form and click the button to verify that there are no errors and that your repeating table populates with the Active Tasks only (Fig 12).


    Fig 12 - Repeating table in main data source showing Active Tasks

    Publish the Form and Verify Success

    • Publish the form, go to your Meeting Workspace, and click New in the form library
    • Fill out the form as much as you want
    • Click the Show Active Tasks button, ensure it populates the table, and then click Save to save the form back to the library
    • When you see the XML form in the library, click on it and verify that you still see the data
    • Close the form, then go change an active task to mark it as completed so that it doesn't show up in our Active Tasks view (Fig 13/14)



    Fig 13/14 – CopyTable task complete and no longer active

    • Re-open your existing form (Fig 15) and notice that you still see the previous data (3 tasks, not 2). This is the desired behavior, because we want to know the status of our Active Tasks at the time of the meeting, not later after the meeting when we re-open the form. If we were only showing the secondary data source, then we would always see the current Active Tasks, which is not desired. If you were to click the button again, then it would update with the new tasks, but that is not the intent here (feel free to apply conditional formatting to hide the button after it is saved). You would only hit the button on new forms when conducting future meetings.


    Fig 15 – Final view of completed form

    • Another point of note is that we aren't using the Auto-Generating Filenames for InfoPath Forms concept, because if you use submit in a Meeting Workspace, then it saves the XML form to the root of the form library, which then makes it not visible to any of the recurring meeting dates. Using save allows it to save to its respective meeting (Fig 16) date and thus only see one form per meeting and ensuring that you only see the snapshot of active tasks at that given date.


    Fig 16 – Saved form shows up in proper meeting date

Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.