Moving InfoPath fields from one group to another is a known difficulty. Well, it’s not difficult. It just takes a couple mouse clicks per field, and there’s no drag-and-drop (Note: this has worked very well for me for forms where the views have not yet been set up. See the bottom of the post to see what happens when you change the schema in this fashion if the views have already been created). So the typical scenario is, click on the field and select move:
That brings up the move field dialog:
Then, select the folder you want to move the field to, and then click ok. That makes a grand total of four mouse clicks per field. It’s easy, but it’s a pain if you need to move a larger number of fields. The solution? Work with the XML source files. No, this solution is not for the squeamish…
(I should emphasize, this is for moving fields from one group to another. If you’re just trying to reorder fields, then check out: http://blogs.msdn.com/infopath/archive/2006/05/04/590005.aspx)
First, move one field using the mechanism described above. You don’t have to, but I think it will make it easier to work with the XML if you already have one moved. Then, save the form as source files. (If you haven’t done that before, check out: http://office.microsoft.com/en-us/infopath/HP100646591033.aspx?pid=CH100476441033)
After saving the source files, find the file called “myschema.xsd”, and open it with your favorite xml editor (notepad will suffice). Once there, look around for two things: the fields you’re trying to move, and the group you’re moving them to.
So, in my example above, I had moved a field called “aa” into a group called “NewGroup”. The following is how it is displayed in the schema file:
Note in the above code that “aa” is listed twice. Once with ref and minOccurs attributes, and once with name and type attributes. For this task, I will not be touching any element with name and type. The elements with name and type define that the field exists, and identify the data type. However, it is the elements with the “ref” attribute that define in which group the field is located. So, all I have to do is find the other fields (the elements with the ref and minOccurs attributes), and cut and paste them to be alongside of the “aa” element already there:
A similar procedure should be done with the Template.xml file and sampledata.xml. If you don’t you’ll wind up adding the field to a view and seeing:
The blue icon in the above example is there because the field was moved in the schema file, but not the template.xml file.
Save and close out of the xml editor. R-click on manifest.xsf, and select design. Your form will open and the fields will have all been moved:
No, I don’t use this to move three fields. But when I have eighty to move, it’s been a big help to me.
Moving fields when they have already been added to the form
This system is far from perfect. If you have already built your views (added fields to a page) before changing the schema, then you will see the following:
The above shows what happens when the schema is changed, but the view is not. So the fields no longer know where they are supposed to store their data. You could:
- Go customize the view.xsl file…. This works, but the time savings become, shall we say, less apparent?
- R-click on the field and select “change binding”. This works, but it takes just about as long as just moving the field with the UI to begin with.
- Delete and re-add the fields to the view. As long as there’s hasn’t been much work done on the form, this could be a viable option. Otherwise, you may have to just move the fields with the UI one at a time.