We have a form at work where the XPath current() function isn’t working properly. It’s supposed to be essentially a pointer to your current execution context, so in InfoPath in general it’s great for finding your way sort of recursively up and out of your current context to sibling controls (for harvesting lookup values, etc.). When it works.

Read on for more details.

InfoPath 2007 doesn’t seem to have any problem with this, but say we want a field’s default value to change depending on the value of another control in the same row of a repeating table. This isn’t particularly far-fetched and would be a great way to deal with a form that figures out total invoice values based on a secondary data source (like a SharePoint list, or a database or whatever). That’s actually what our users are trying to do.

Here’s the idea.

Start with a SharePoint list of various attributes to parts (part number, part description, cost for various lease terms, monthly payments, outright purchases, whatever).

Create a Form Library on the same site. Edit the form template in InfoPath (2003 for me).

In the main data source, rename the root to “root” (via Properties) create a Repeating Table Container group off the root of the data source (called RepeatingTableContainer). Then create a Repeating Table off that group (called RepeatingTable). Within the Repeating Table group, create 2 nodes: PartDescription and PartCost.

Click and drag the RepeatingTableContainer group to your form.

Change the PartDescription field to a Drop-Down List. Right click and choose Properties. Hook it up to your lookup SharePoint list. For now, assuming your descriptions are unique, just set both value and description to the part description. I haven’t quite figured out how to extract the dropdown list value compared to description in an XPath expression.

Also right-click the PartCost field and go into its Properties. Here’s where the broken XPath comes in. Choose the fx button next to the Default Value, then click the Edit XPath checkbox.

Use a form of this XPath expression in the form of:
xdXDocument:GetDOM("Equipment Price List")/dfs:myFields/dfs:dataFields/dfs:Equipment_Price_List/@_30-90_DAYS[../@Part_Description = current()/../my:PartDescription]

where:

• “Equipment Price List” is the name of your secondary data source that you used to populate the dropdown list.
• _30-90_DAYS is the name of the field in that lookup list as far as SharePoint’s concerned (you’ll need to do some funky crap with that like editing the field in SharePoint’s Modify settings and columns UI and further http decoding the thing in order to figure out the field name in SharePoint’s lala land).
• Part_Description is likewise the name of the field in that lookup list as far as SharePoint’s concerned of the part’s description.
• my:PartDescription is the field name of the dropdown list you’re keying the lookup off of in the InfoPath form.

Now the current() function in this context is supposed to say that the Part Cost field in this particular repeating table row that you’re in is the one that is returned here. The .. means that you should go one level up into the row of the repeating table and the /my:PartDescription says look for the value here in the dropdown list in the same row.

But in InfoPath 2003, that’s not working so well, and something’s busted about the current().

Because a function call that does work (wrongly) and does look up the wrong data (always from the first row of the repeating table) is this one (in the entire XPath expression):
xdXDocument:GetDOM("Equipment Price List")/dfs:myFields/dfs:dataFields/dfs:Equipment_Price_List/@_30-90_DAYS[../@Part_Description = xdXDocument:get-DOM()/my:root/my:RepeatingTableContainer/my:RepeatingTable/my:PartDescription]

Anyway, we’re currently escalating this issue with Microsoft right now. Will update later if we resolve anything.