Repeating tables are beautiful things. It is the most elegant implementation of dynamic data inputting I've ever seen. However, the beauty quickly fades after going from the UI to the code behind. To start, simply enumerating a table is onerous enough. This entails getting into the InfoPath DOM, and literally looping through the auto-generated XML using an XPath query.

So if we only need to iterate a column in a table looking for a particular value, then this isn't too bad. But consider nested tables. Then consider repeating nested tables. Then consider repeating nested tables in conditional repeating sections. Then consider dropdown lists that need to be filled and button clicks that need to be handled in repeating nested tables in conditional repeating sections. This code will get really messy really fast.

Going up a level, and really coming to the first non-intuitive sub topic here, we have row isolation. If there is a control in a row of a repeating table, and the user creates new rows, InfoPath considers each control to be the same; if a textbox, for example, appears in fifty rows, there will be fifty values in the XML, but only one event handler, one set of rules, and one arrangement of conditional formatting.

This, or course, raises the question: how can it be determined which dropdown list was changed, or which button was clicked? Without a little "InfoPath magic," there is not enough known to properly handle an event. Here is how I isolate a row in a repeating table:

1. Create your table.  For this brief example, we'll use a textbox and a button.
2. Create a hidden textbox outside of the table.  This will be our event handler.
3. Open the rules for the button.  Create a rule that sets the value of the hidden text box equal to the value of the textbox in the table.  You will notice that there is only one entry for this textbox in the field selector.  The context of the button click (or any event) is the row that is in focus.  Therefore, selecting this field is selecting the value of the textbox in the row in which the event occurred.
4. This will fire the event of the hidden textbox.  Use rules or the event handler for this control to perform whichever action is necessary on the value.  This textbox can be used over and over again to represent any value in that row.  This is how the isolation is performed.
5. Finally, use the rules or event handler of the button click to update any of the controls in the row with the new value of the hidden textbox.  Remember: rules fire before the event handler, so keep this in mind as you react to events.

Not too bad. Now, the final challenge of repeating tables is their auto-population. Like I said, repeating tables are great for letting users create as many rows as they need. However, can code-behind perform the same feat? Well, it can, but it takes quite an effort. I spent a lot of time digging through the InfoPath API and its documentation, but no obvious solutions presented themselves. I tried adding nodes to the table, manually manipulating the XML, and creating new controls. Nothing worked.

So here is how I auto-populate a repeating table: