InfoPath Dev

I am working on a form that tracks invoices from suppliers so that we have a full record of all invoices received from each individual supplier.  In one of my views I have set up a master/detail section in which users can enter the current invoice details while updating the historical invoice details at the same time.  I know I'm using it kind of backwards, but for my purposes users will enter all the data into the "Detail" section and the "Master" section will hold basic details about each invoice. Users will then insert a new "Detail" section rather than inserting a new Master section each time a new invoice is received (insert controls have been disabled on the Master).  What I would like to happen is for a user to insert a new Detail section and when the new row is inserted in the Master repeating table, the row is inserted at the top of the table rather than the bottom - this way the historical invoice info will sorted newest - oldest.  I know that when the insert/delete controls are enabled on the master, you can manually select to insert a row above but can't find any way to do this as a default.  I've searched all over but can't seem to find a simple solution...any ideas?  Screen shot of the form is attached so you can get an idea of what I'm doing.

Ben

 It's not the smoothest solution, but please try the attached XSN.

How I did it:

1. Open up the Master repeating section's properties, click the Advanced tab and get the control's ViewContext ID (something like CTRL1_5)
2. Save the template as its source files and open the XSL file that corresponds to the view where this Master/Detail control is.
3. Search for the ViewContext ID in the file and find the XSL that corresponds to the Master section.  In my case it looks something like this:
   <tbody xd:xctname="RepeatingTable" xd:masterName="CTRL1_5">
          <xsl:for-each select="my:group1/my:group2">
               <tr>
                      ... contents abbreviated
               </tr>
          </xsl:for-each>
   </tbody>
4. Add an xsl:sort line immediately after the xsl:for-each line, so the whole bit looks like this (you can copy the xsl:sort line exactly as it is here):
   <tbody xd:xctname="RepeatingTable" xd:masterName="CTRL1_5">
          <xsl:for-each select="my:group1/my:group2">
               <xsl:sort select="position()" order="descending"/>
               <tr>
                      ... contents abbreviated
               </tr>
          </xsl:for-each>
   </tbody>
5. Reopen and preview the form.  New rows will be added at the top of the master table.

One significant drawback here is that InfoPath does not expect you to make manual changes to the views' XSL, and as a result, has a tendency to overwrite changes you have made to it any time you make a change to the view, and this is one of those cases.  So this means you will need to re-edit the XSL any time you make a change to the view.  If you think you will be making few enough changes that this won't become a huge hassle, I welcome you to give this approach a try.

Thanks Jimmy, this worked great!  I had actually found the xsl:sort option previously but couldn't get it working as I hadn't included the () at the end of "position".

Regarding Infopath's tendency to overwrite the changes, I was also reading about preserve code blocks in conjunction with the xsl:sort in order to preserve the code so InfoPath doesn't change it everytime.  Is this something you're familiar with?  When I tried doing it previously I didn't have any luck with it.

Failing that, will I only need to amend the .xsl if I make changes to that specific view?  Will it be affected by any changes (e.g adding new fields, adding additional options to ddl's etc) or is it only affected by changes made to the node I'm forcing the sort on?

As always, thanks so much for all your help - I'd never get anywhere without this site!

 Good job finding out about preserve code blocks.  I'm not that knowledgeable about the topic, but I gave it a try and unfortunately it doesn't seem like it will work in this case.  The special relationshp between the master and detail controls means that when the master part is in a preserve code block, the detail control doesn't work properly.

To answer your question, you should be able to modify the  data source, add other views, and modify the other views without re-editing the XSL, but any changes within the view where the control is (even if not on the control itself) will cause the XSL to revert.

Yes, I'm becoming quite an expert at trolling through these pages and google looking for answers - it's the downside to being the resident InfoPath expert here!

Thanks again for your help, in this case I don't think it will be too much of an issue to re-edit the xsl if need be as it's a pretty small modification and there (hopefully!) won't be too many alterations to this view once the form is up and running.