Use of the Current() Function
One of the most annoying things that can happen in InfoPath is a problem that occurs when you are using Filtered Data to populate a second dropdown from the results picked in an initial dropdown in a repeating section or repeating table (a.k.a. cascading filtered dropdowns). The problem can also arise in rules that set values of another field based on the selection of a dropdown value from inside a repeating table or repeating section. The issue is that InfoPath doesn't know which node to refer to when you are in a repeating set of nodes, so it chooses the first set of values in the node. This problem is particularly challenging because you don't see an issue until you add the 2nd node of a repeating section. Often the users of your solution will find this before you do. The trick here is that you need to delve a little into the underworld of XPath to get the right result. Let's deal with the Filtered Data example first, because it's easier. It's easy to set up the first dropdown values, that's a straightforward link to a secondary datasource. The second set of dropdown values is simple to link in, but now you need to click on filtered data in order to give the query some criteria to limit the entries. When you do it you'll end up with a line that looks like the first one below. It is in the filter properties that we need to get fancy and use the current() function. When you look at the filter, what you need to do is to click on Modify, and in the left-most drop down you need to select "The expression". That will show you the XPath version of what you are actually doing. You'll need to modify the line so that it looks like the After: entry.
Before:
<../@somevaluefromsecondarydatasource=xdXDocument:get-DOM()/my:myFields/my:someothervalue>
After:
<../@somevaluefromsecondarydatasource=current()/my:someothervalue>
Now that doesn't look too hard, and it isn't, but sometimes it doesn't work. I'm not an expert in traversing XML nodes using XPath, but I do now that the next thing to try when this fails is to change the line to read current()/../my:someothervalue. I think this nomenclature is to force the code to start at the top of the XML node tree and then look down through, as opposed to starting where the current pointer in the node happens to be. Don't quote me on that however because I've never been able to confirm that my inkling is correct. This line will look more complex is the form you've built is based on a SQL or Access database. You'll see stuff after the equals sign like xdXDocument:get-DOM()/dfs:myFields/dfs:dataFields/d:someothervalue, but all it's really doing is refererences a different schema related to the data connection you have with the database, so don't panic.
It gets trickier when you are setting up a rule that does a lookup and sets a value of another field. Most typically you have a secondary datasource with at least two fields; the first field is used to populate a dropdown box in the repeating table/section, and the second field is populated by doing a lookup using filters where the value chosen in the dropdown equals a lookup value in the secondary datasource. I'll assume that you can figure out how to build the filter using the standard GUI. The trick will be now that the filter criteria is embedded in a longer line; typically the filter criteria is within brackets [ ]. You do the same procedure though, by changing what comes after the equals sign and putting either current()/ or curren()/../ in place of all the garbage that leads up to the actual nodename that you are filtering on (i.e. my:someothervalue).
All of this sounds complicated, and you can probably guess that I've struggled with it over time, which is why it belongs in my Blog. If I'm too obtuse for you, you can try the other Blog entry that I've referenced below.