David Fries' WebLog : InfoPath

Status Reports in InfoPath (Part II)

davfries — Mon, 04 Oct 2004 06:13:00 GMT

Due to the overwhelming number of requests (3+) for screenshots and code for the Status Report described in a previous post , I've decided to make them publicly available. My only request is that you let me know how I can improve the form.

Here is the "Individual View":

It uses a Master-Detail control for viewing multiple Status Reports at once.

Here's the "Team View"

It groups things by section, rather than by person. I had to use a secondary data source and some scripting to get this to work. Perhaps someone can come up with a more elegant solution.

Here is the original form template. Also included are the two data sources (Access databases) that the form depends on.

A couple of notes on running this form:

I created an access database for the form to run in, but the form is currently hardcoded to look for the Access DB at C:\StatusReport\. Unzip the files to that location for the form to run properly. When you deploy the form to users, you should put the Access DB in a shared location, or use SQL Server.
The original form uses a Web Service to get the current user name. I had to remove this in order for this form to be functional, and I replaced it with a call to the WScript.Network ActiveX control. Unfortunately, this ActiveX control is unsafe, and requires the form to be Fully Trusted. Until you get your own web service written, you can test the functionality of the form by opening it in the Designer and Previewing.

If you have any questions or problems, let me know.

Status Reports in InfoPath

davfries — Tue, 28 Sep 2004 17:21:00 GMT

When I transitioned from the InfoPath team to the CLR team, I wanted to take some of my knowledge of InfoPath and put it to good use here. After browsing the intranet sites, I noticed that there had been several different attempts at designing a status reports system. While InfoPath isn't the right tool for every situation, status reports are a perfect fit.

The status reports system I designed for my team has the following features:

SQL Server 2000 backend
Auto-detection of employee name, manager name (from a web service)
Unfinished and new items from previous week are automatically populated for the current week
Validation so that submission can only happen on Fridays (makes it easy to query later)
Query by employee, manager, team, or date.
Master-detail view for viewing multiple status reports.
Roll-up view (displayed by section, not person) for viewing
Color schemes for the different views to make them easily distinguishable

If anyone's interested, I can post some sceenshots and/or code up.

InfoPath SP1 SDK released

davfries — Sun, 08 Aug 2004 00:46:00 GMT

Get it here...before it gets you!!!

http://www.microsoft.com/downloads/details.aspx?FamilyId=351F0616-93AA-4FE8-9238-D702F1BFBAB4&displaylang=en

Repeating, Multiply-Cascading, Dropdown Listboxes with Unique Entries in InfoPath

davfries — Thu, 29 Jul 2004 11:06:00 GMT

First, a few definitions:

Repeating: Inside of a Repeating Section or Repeating Table control

Cascading Dropdown Listboxes: This is where the selection in one dropdown listbox causes the available items in another dropdown listbox to be updated. For example, If I choose “Ford” for the “Make: “ dropdown listbox, the “Model: “ dropdown listbox will be updated to only show vehicles made by Ford.

Multiply-Cascading Dropdown Listboxes: That's pronounced mull-tih-plee, and is a term that I made up. This is similar to the previous concept, but this allows you to choose an item from any one of multiple dropdown listboxes, and it will filter out the values in all other dropdown listboxes.

Unique Entries: Any duplicate items for the dropdown listbox will be filtered out.

Ok, now down to business:

The scenario: You have a photo album that allows viewing photos in groups based on selections in dropdown listboxes. You have information about each photo's title, date, location, and web URL. When you select a value from one of the dropdowns (say, location = “Denver“) then you want all the other dropdowns to filter themselves

First, let's describe an XSD file which you will base your form off of. (photoalbum.xsd):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xsd:schema targetNamespace="http://schemas.microsoft.com/office/infopath/2003/myXSD/2000-01-01T12:00:00" xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD/2000-01-01T12:00:00" xmlns:q="http://schemas.microsoft.com/office/infopath/2003/ado/queryFields" xmlns:d="http://schemas.microsoft.com/office/infopath/2003/ado/dataFields" xmlns:dfs="http://schemas.microsoft.com/office/infopath/2003/dataFormSolution" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
     <xsd:element name="myFields">
          <xsd:complexType>
               <xsd:sequence>
                    <xsd:element ref="my:PhotoAlbum" minOccurs="0"/>
               </xsd:sequence>
               <xsd:anyAttribute processContents="lax" namespace="http://www.w3.org/XML/1998/namespace"/>
          </xsd:complexType>
     </xsd:element>
     <xsd:element name="PhotoAlbum">
          <xsd:complexType>
               <xsd:sequence>
                    <xsd:element ref="my:Photo" minOccurs="0" maxOccurs="unbounded"/>
               </xsd:sequence>
           </xsd:complexType>
      </xsd:element>
      <xsd:element name="Photo">
           <xsd:complexType>
                 <xsd:sequence>
                      <xsd:element ref="my:Title" minOccurs="0"/>
                      <xsd:element ref="my:Location" minOccurs="0"/>
                      <xsd:element ref="my:WebSite" minOccurs="0"/>
                  </xsd:sequence>
            </xsd:complexType>
     </xsd:element>
     <xsd:element name="Title" type="xsd:string"/>
     <xsd:element name="Location" type="xsd:string"/>
     <xsd:element name="WebSite" type="xsd:string"/>
</xsd:schema>

Use this schema, and create a new form from Data Source.

Right click on the Photo node in your data source, and insert a Repeating Table control.

Right click on each of the textboxes in the table columns, and convert them to dropdown listboxes.

Now that you've gotten your form layout mostly node, let's add an XML file that will serve as the data source for the items in each of the dropdown listboxes:

Here is some sample XML to use (Event.xml):

<?xml version="1.0"?>
     <PhotoAlbum>
           <Event Title="My Dog" Date="2004-10-31T12:00:00" Location="Redmond" Website="http://www.images.com/Dog" />
            <Event Title="My Parents" Date="2002-07-04T12:00:00" Location="New York" Website="http://www.images.com/Parents" />
           <Event Title="My School" Date="2001-01-01T12:00:00" Location="Denver" Website="http://www.images.com/School"/>
           <Event Title="My Car" Date="2000-01-01T12:00:00" Location="New York" Website="http://www.images.com/Car"/>
            <Event Title="My Ski Trip" Date="2005-01-01T12:00:00" Location="Denver" Website="http://www.images.com/Ski"/>
</PhotoAlbum>

Save this file somewhere, and then add it to your form as a resource (Tools->Resource Manager). Name the secondary data source “Event“

Now you can hook up the dropdown listboxes so that their items come from the “Event” data source.

Now is where it gets a bit ugly. InfoPath doesn't have UI to create these magical cascading dropdown listboxes. However, you can edit the current view's xsl file in order to achieve the desired effect. In order to edit the XSL file, you'll need to Extract (File->Extract Form Files) into a folder. Once you have your form extracted, you can edit the view1.xsl file like so:

<select class="xdComboBox xdBehavior_Select" title="" style="WIDTH: 100%" size="1" xd:CtrlId="CTRL7" xd:xctname="DropDown" value="" xd:boundProp="value" xd:binding="my:Title" tabIndex="0">
     <xsl:attribute name="value">
          <xsl:value-of select="my:Title"/>
     </xsl:attribute>
     <xsl:choose>
          <xsl:when test="function-available('xdXDocument:GetDOM')">
               <option/>
               <xsl:variable name="val" select="my:Title"/>
               <xsl:variable name="loc" select="my:Location"/>
               <xsl:variable name="web" select="my:WebSite"/>
               <xsl:for-each select="xdXDocument:GetDOM("Event")/PhotoAlbum/Event/@Title[((../@Location = $loc) or $loc ='') and ((../@Website = $web) or $web ='') and not(.=../preceding-sibling::*/@Title)]">
                    <option>
                         <xsl:attribute name="value">
                              <xsl:value-of select="."/>
                         </xsl:attribute>
                         <xsl:if test="$val=.">
                              <xsl:attribute name="selected">selected</xsl:attribute>
                         </xsl:if>
                         <xsl:value-of select="."/>
                    </option>
               </xsl:for-each>
          </xsl:when>
          <xsl:otherwise>
               <option>
                    <xsl:value-of select="my:Title"/>
               </option>
          </xsl:otherwise>
     </xsl:choose>
</select>

The edits you'll need to make are in red. There are also two other places (for the other two dropdown listboxes) where you'll need to make similar changes. I will leave that as an excercise for the reader. Here's an XSLT reference, for those of you who actually made it this far :)

More bad news... The InfoPath Designer has a tendency to overwrite any changes you make to the xsl. The way to keep your hand-edited xsl from being overwritten is to use an xd:preserve template.

The good news is that once you've done all this, you have fully achieved your goal of having repeating, multiply-cascading dropdown listboxes with uniqe entries., and you didn't have to write a single line of code to get them (some might argue that XSLT is worse to deal with than code, but that's another matter!)

This may be a lot easier using the Filters feature in InfoPath SP1, but I do recall that the SP1 Filters feature does not include showing only unique entries in a dropdown listbox.

Don't feel like messing with all this, but you still want to see what it looks like? Shoot me an email, and I'll send you a copy of the form.

Office 2003 SP1 Released! (Including InfoPath)

davfries — Tue, 27 Jul 2004 19:07:00 GMT

Download it here.

Instructions for SP1 Preview users here.

Random monkeys dancing here.

Fun with VBScript in InfoPath

davfries — Sun, 25 Jul 2004 01:47:00 GMT

Say you want to pop-up a dialog to the user to get some information. You could use the XDocument.UI.ShowModalDialog method, but this is Level 3, meaning you can only call it from Fully Trusted forms. You could also use managed code business logic and create a WinForm to display to the user, but that requires InfoPath SP1 functionality, not to mention that that seems like a lot of work just to throw a dialog with a input box.

VBScript to the rescue! VBScript has 2 methods which are quite useful in InfoPath, and are not available in JScript: MsgBox and InputBox

MsgBox throws a dialog with different buttons (OK, Cancel, Yes, No). (Note, InfoPath SP1 has a method which has similar functionality. XDocument.UI.Confirm)

InputBox throws a dialog with a text box. You can then take the information that the user types into the text box, and use it in your InfoPath form.

This example shows how to call the InputBox method, and as a bonus, adds the value as a new item in a secondary data source/data connection (in this case, an XML file). You can have a dropdown lisbox control which gets its values from the secondary data source/data connection. This provides a cool way for the user to add a new item to the dropdown listbox.

First of all, you'll need to set your scripting language to VBScript. You can set this from Tools->Form Options->Advanced Tab. Do this before you start writing any script, otherwise you won't be able to change it.

Once you've set your scripting language to VBScript, now you're ready to start adding events. Add a button to your form, change the label and ID to GetName, and then click on the “Microsoft Script Editor” button (In SP1, this button is now labeled “Edit Form Code“)

In the script editor, add the following code:

Sub GetName_OnClick(eventObj)
     Dim name
     Dim oAuxDOM
     Dim oNewCustomer
     name = InputBox("Enter customer name:")
     Set oAuxDOM = XDocument.GetDOM("customers")
     ' Create a new customer element
     Set oNewCustomer = oAuxDOM.createNode(1, "customer", "")
     oNewCustomer.text = name
     oAuxDOM.selectSingleNode("//customers").appendChild(oNewCustomer)
     XDocument.View.ForceUpdate()
End Sub

You might have noticed in the script above that there is a secondary data source/data connection called “customers“ which we haven't added to our form yet. We'll add that now. Create a new file in notepad and call it customers.xml:

<?xml version="1.0" ?>
<customers>
<customer>ABC Tile Co.</customer>
<customer>ACME Brick</customer>
</customers>

Add this file to your form using the resource manager (Tools->Resource Manager in InfoPath RTM, Tools->Resource Files in SP1)

Then create a secondary data source using this resource xml file (Tools->Secondary Data Sources in InfoPath RTM, Tools->Data Connections in SP1)

Finally, add a dropdown listbox control to your form. From the properties dialog for the dropdown lisbox, choose to “Look up entries in a database, web service, or file” (Again, in SP1, this text is different, but similar) Set the Data Source dropdown to be the “Customers“ data source, and set the Entries to bind to the /customers/customer node. Leave value and display name as “.“

That's it! Preview the form and give it a try. If all goes well, every time you type something in the VBScript InputBox, it gets added to the end of your dropdown listbox. Not bad for less than 10 lines of script.

Debugging Fully Trusted InfoPath Forms with Managed Code Business Logic

davfries — Wed, 14 Jul 2004 01:23:00 GMT

That's a mouthful, isn't it?

First of all, you know what I mean by managed code business logic in InfoPath, right?

Also, you know what a Fully Trusted InfoPath Form is, right? If not, here's a refresher.

Let's say you're a form developer, and you've been tasked with developing a form which requires managed code business logic AND calls into InfoPath Level 3 OM (like XDocument.UI.ShowModalDialog).

So, you start Visual Studio.NET 2003, choose to create a new InfoPath Project (you did install the InfoPath 2003 Toolkit for Visual Studio.NET, right?) , and choose Visual C# Project. Finish the wizard, and you've got yourself a managed code InfoPath form. To debug the form, all you need to do is hit F5, and the debugger will launch.

Now, let's make the form Fully Trusted. You have 3 options:

Register the Form (via a script/msi created by using RegForm Tool in the SDK)
Register the Form (via a handwritten script which calls Level 3 OM method Application.RegisterSolution)
Sign the Form (you can create a test code signing certificate using the InfoPath Designer)

One other thing to note: When working with InfoPath VS Projects, the form is in “extracted” format, meaning all the xsd, xsl, xml, and other files are sitting in a folder, as opposed to all wrapped up in an .xsn file (which is the default way to deploy forms). When you are ready to deploy your form to your users, use the Publishing Wizard to generate an .xsn file for your form.

Back to the matter of making the form Fully Trusted.

RegForm: Since you're working with extracted form files, you won't be able to use the RegForm tool in the SDK. If you MUST use RegForm, here are the steps:

Publish the form to generate an .xsn file
Run RegForm on the .xsn file to generate a .js file to register the form
Run the .js file to register the form.
Start the form, then attach VS to the InfoPath process to debug.

But wait, there's more... After you've made a change to your code, you'll need to unregister the form, delete js files, republish the form, etc. It all gets very messy.

Signing Forms: You also won't be able to use the signing method to make your form fully trusted, for the same reason. You can't sign extracted form files. You'll have to publish the form, sign the published .xsn, and then attach VS to the process in order to debug. You'll need to do this step every time you make a change to your code. Again, this is less than ideal.

RegisterSolution OM: The only other method remaining is to register the form without using RegForm. You can simply write your own .js file which calls RegisterSolution(), and register the manifest.xsf in your project folder.

1. Open the manifest.xsf and remove the publishURL. (required to make the form Fully Trusted)
2. Write a script file which calls into InfoPath External Automation to call RegisterSolution on the manifest.xsf file.

'Sample courtesy of Jeff Webb
'http://www.mcse.ms/archive180-2004-4-605806.html
set ip = CreateObject("InfoPath.Application")
Set fso = CreateObject("Scripting.FileSystemObject")
pth = fso.GetFolder(".").path
ip.registersolution pth & "\manifest.xsf"
set ip = nothing
set fso = nothing

3. Run the script file.

Now you should be able to simply hit F5 to debug your form, and it should be able to successfully call any InfoPath Level 3 OM Methods (XDocument.UI.ShowModalDialog, etc) without a security exception. Changes to your code are also automatically updated without having to republish. Sweetness.

Note: When you're ready to deploy your form to your users, you should still publish your form, and utilize RegForm or code signing certificates to make your forms fully trusted. This posting is simply talking about how to debug your form without losing your mind.

InfoPath SP1 Security

davfries — Fri, 09 Jul 2004 05:25:00 GMT

Note: This post doesn't go over the SP-1 deployment model. If you want to learn about that, read this post from the InfoPath Team blog.

InfoPath has a rather unique security model. It borrows a bit from IE, a bit of its own, and with SP1, it adds a little bit of .NET security to the mix.

IE Security: Internet Explorer security is based on the Zones concept. There are 5 zones (going from most restrictive to least restrictive) Restricted, Internet, Intranet, Trusted Sites, and the non-configurable Local Machine zone. If your webpage has script which tries to create an unsafe ActiveX control (like FileSystemObject), it will get an error on every zone except Local Machine, and Trusted Sites, where you will be prompted. Also, if your script tries to access a resource on another “domain” (a.k.a website), you will get access denied in the Internet Zone, prompted with that friendly “This page is accessing information that is not under its control. This poses a security risk. Do you want to continue?” dialog in the Intranet Zone, and your call will succeed on the Local Computer or a Trusted Site. If you had script in an InfoPath custom HTML task pane, it would naturally behave the same way.

InfoPath-specific Security:InfoPath can run script in a custom HTML task pane, but it also can run script as built-in business logic to respond to events like OnLoad of the form, or OnClick of a button. InfoPath has its own Object Model, and each property or method has it's own security level:

Level 0: Level 0 properties/methods can be called by anyone, anywhere. They are very innocuous methods that are considered safe no matter who calls them. (Ex. Application.FormatString)
Level 2: To understand level 2 methods, you need to understand that InfoPath forms can communicate with each other. I can say Application.XDocuments.Item(1) from my business logic and get access to another form that's currently running on the machine. Whether or not this call will succeed or not is based on whether the Form Template (xsn) file is located on the local machine or Trusted Sites, the Intranet Zone, or the Internet Zone.(InfoPath forms don't run if the Form Template (xsn) file is located in the Restricted Zone). In addition, any paramaters in a method call are checked to make sure they are not accessing information in another Domain. The vast majority of the InfoPath OM is level 2 (Ex. XDocuments.Open, XDocument.UI.Alert, etc)
Level 3: These methods/properties are considered unsafe no matter who is calling them. The only way to prove that you are trustworthy enough to call them is if your form template is Fully Trusted. This means that you must register the form call the ExternalApplication (or just Application in SP1) RegisterSolution method, or you can digitally sign the form (SP1 only). You can also use the RegForm tool in the InfoPath SDK to generate a .js or .msi file to register the form for you.

.NET Security: With InfoPath SP1, you have the option of writing business logic in managed code. I won't get into all of the details of Code Access Security, but let me say this. InfoPath Forms with managed code business logic, unlike regular .NET console applications, do not have FullTrust permissions on the local machine. It is granted the LocalIntranet Permission Set instead. This means you won't be able to willy-nilly create TextWriters and overwrite your friend's boot.ini file just by getting him to open an InfoPath form. It also means you won't be able to create TextWriters (and many other .NET Framework Objects) while you are developing your form. If you'd like to learn how to configure the InfoPath Form Templates group using the .NET Configuration 1.1 utilitiy, check out this page from Roger Jennings (Note: There's a security warning in there about how not to expose yourself to attack. READ IT!)

Putting it all together:

These are just a few interesting facts that “naturally“ (or not so naturally) fall out of the 3 security models

Granting your managed code business logic FullTrust Permissions will have no effect whatsoever on your script running in the custom task pane.
Running a form with managed code business logic from a IE Trusted Site will cause the business logic to fail with a security exception. Why? .NET Security grants IE Trusted Sites the Internet Permission Set by default. InfoPath forms with managed code business logic won't even open in the Internet Zone.
Granting Full Trust to managed code business logic does not entitle you to call InfoPath OM Level 3 methods.
Granting your InfoPath form Full Trust (by registering or signing it) does entitle your managed code business logic to the FullTrust permission set.
Communication between the taskpane and managed code business logic requires that your managed code has FullTrust permissions (because it needs to call into unmanaged code). If your form needs to communicate with the taskpane, try to stick with script for your business logic, if you can.
Email-deployed forms will not be able to use managed code business logic.
Do not taunt Happy Fun Ball™

InfoPath 2003 SP1 and Active Directory

davfries — Tue, 29 Jun 2004 19:23:00 GMT

I figured I'd be the only one in the developer division not blogging about Beta 1!

When I was on the InfoPath team, I wrote a hands on lab (Lab 15)which talked about using managed code with InfoPath. Excercise 3 of the lab talked about using managed code to access information in Active Directory using System.DirectoryServices.

While this seemed like a great idea at the time, I've since realized that there's a better approach to the problem.There's really only one big problem, and that's that System.DirectoryServices requires FullTrust permissions in order to run. Since InfoPath forms by default do not have FullTrust permissions granted, you'll have to jump through all sorts of hoops in order to run the form (that's a blog for another time).

A better approach is to have a machine with a Web Service on it which exposes the information from Active Directory that you need. This way, you don't need to make your form fully trusted, making it easier to deploy. In addition, other forms can hit your webservice, so you can reuse your code. Also, by using a web service, you don't even need InfoPath SP1! You can use data adapters to connect to the web service, and script to populate the fields you want populated.

Here's the code for the web service, which is almost verbatim taken from the lab.

using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Web;
using System.Web.Services;
using System.DirectoryServices; 
namespace WhoAmI
{
  /// <summary>
  /// Summary description for Service1.
  /// </summary>
  [WebService(Namespace="http://davfries.foobar/whoami/")]
  public class Service1 : System.Web.Services.WebService
  {
    public Service1()
    {
     //CODEGEN: This call is required by the ASP.NET Web Services Designer
     InitializeComponent();
    }
...
   [WebMethod]
   public string GetName()
   {
      return System.Environment.UserName;
   }
   [WebMethod]
   public string GetDomain()
   {
     return System.Environment.UserDomainName;
   }
   [WebMethod]
   public string GetManager()
   {
     // get current user name
     string strUserName = System.Environment.UserName;
     // search for user whose mailNickname is the logon name

DirectorySearcher ds = new DirectorySearcher("(mailNickname=" + strUserName + ")"); SearchResult result = ds.FindOne(); if(result == null) { return "Error finding user " + strUserName + " using Active Directory."; } DirectoryEntry employeeEntry = result.GetDirectoryEntry(); // find manager's LDAP DN from the DirectoryEntry string strManagerDN = employeeEntry.Properties["manager"].Value.ToString(); // use the DN to create a new DirectoryEntry DirectoryEntry managerEntry = new DirectoryEntry("LDAP://" + strManagerDN); // get the alias of the manager string strManagerAlias = managerEntry.Properties["mailNickname"].Value.ToString(); return strManagerAlias; } } }

Then, in InfoPath business logic, you would have (something like) the following code:


IXMLDOMNode nodeManager = 
thisXDocument.DOM.selectSingleNode("my:SalesReport/my:manager");
nodeManager.text = XDocument.GetDOM("GetManager").selectNodes("/dfs:myFields/dfs:dataFields/d:GetManagerResponse/d:GetManagerResult").text;

I hope this is helpful...