locked
Does any one know how to alphabetize the form field in Infopath? RRS feed

  • Question

  • Does any one know how to alphabetize the form field in Infopath? I have around 240 fields in my infopath form.
    Thursday, March 24, 2011 2:23 AM

Answers

  • I think she's referring to in her datasource - is this the case Infopath_girl?  Yes, it can be much easier on you to alphabetize them but if this is a form you have in use you're risking changing the xml structure of the form which will make it incompatible with any existing forms based off of this template.

    If you really wanted to alphabetize them, there is no easy way to do it.  You have to manually click "move up" (or down) from the datasource's dropdown menu.  But I highly suggest you do not do this unless it is a form that is not currently in use.

    • Marked as answer by Clayton Cobb Wednesday, March 30, 2011 8:01 AM
    Thursday, March 24, 2011 7:15 PM

All replies

  • What is "the form field"?

    Alphabetize them (you only mentioned one field) where?


    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Thursday, March 24, 2011 4:05 AM
  • I think she's referring to in her datasource - is this the case Infopath_girl?  Yes, it can be much easier on you to alphabetize them but if this is a form you have in use you're risking changing the xml structure of the form which will make it incompatible with any existing forms based off of this template.

    If you really wanted to alphabetize them, there is no easy way to do it.  You have to manually click "move up" (or down) from the datasource's dropdown menu.  But I highly suggest you do not do this unless it is a form that is not currently in use.

    • Marked as answer by Clayton Cobb Wednesday, March 30, 2011 8:01 AM
    Thursday, March 24, 2011 7:15 PM
  • @ Clayton Cobb: Thanks for your reply. https://picasaweb.google.com/lh/photo/hFtf2wkWBZa_6xpmXhUnZsicX8kf4hj85c7iSodco_U?feat=directlink 

    I have marked the area in red where I want to get it sorted.


    Friday, March 25, 2011 3:11 AM
  • @ Clayton Cobb: Thanks for your reply. https://picasaweb.google.com/lh/photo/hFtf2wkWBZa_6xpmXhUnZsicX8kf4hj85c7iSodco_U?feat=directlink 

    I have marked the area in red where I want to get it sorted.



    Ok, so that's your main data source - you want them do all display in alphabetical order in the data source pane?  Melli answered that for you, although moving the fields around should not mess up existing forms at all.
    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Friday, March 25, 2011 3:32 AM
  • This is just a smaple. I have around 240-250 fields. Moving all that up and down will consume lot of time and If a new field is added to the form , that will go and add up all the way down again. So just wondering if I can do it in any other way?
    Friday, March 25, 2011 3:37 AM
  • This is just a smaple. I have around 240-250 fields. Moving all that up and down will consume lot of time and If a new field is added to the form , that will go and add up all the way down again. So just wondering if I can do it in any other way?


    I know - you mentioned 240 fields originally, and then Melli answered, and I confirmed that was the answer.  It is very annoying to not have a bulk move operation or re-ordering button, but that's just how it is.  I actually made this request for the O15 build, so we'll see what happens.  Basically, I'd like to be able to create, move, update, and delete many fields at once in a nice, interactive interface.  For now, though, it's one at a time.  The only other way I can imagine doing it would be to break open the XSN and directly modify the manifest.xsf.

    Why do you want the fields in alphabetical order instead of in logical groupings?  What's the business requirement?


    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Friday, March 25, 2011 3:43 AM
  •  

    @ Melli: Thanks for you reply. Wondering if there is way to alphabetize this in xml?

    To be clear I have a sample form attached to this link -  https://picasaweb.google.com/lh/photo/hFtf2wkWBZa_6xpmXhUnZsicX8kf4hj85c7iSodco_U?feat=directlink  I have marked the area in red where I want to get it sorted.

     

    Friday, March 25, 2011 3:57 AM
  • Hi InfoPath_girl, the link you provided doesn't work.  But, as Clayton mentioned you can modify the manifest.xsf.  One thing thing you could try, is take those fields you want to alphabetize, copy them into excel (including the tag: i.e. <afield> <bfield>), do a sort ascending, then paste them back in.  Make a backup copy of your form before you do this, of course.  I have not tried this method, so it is just a suggestion.

    Clayton:  I did have this break the compatibility in one of my forms once, which is I was I stress to use caution.  BUT that form was a form tied directly to a database (before I got into web services) and I moved a table (group) up in my form.  Then I published it (automatically upgrading existing templates) and the existing forms threw the error referencing the xml structure. 

    Friday, March 25, 2011 12:26 PM
  • Thankyou very much Clayton and Melli. Let me try these options. And yeah I always make a copy/back up before I work on anything. So that I can try out everything I want, in my new version.

    Friday, March 25, 2011 2:29 PM
  • Thankyou very much Clayton and Melli. Let me try these options. And yeah I always make a copy/back up before I work on anything. So that I can try out everything I want, in my new version.


    Not sure how you personally do this, but what I do is save all form template in a SharePoint doc lib with versioning turned on so that I can revert to a previous version if I mess something up.
    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Friday, March 25, 2011 7:48 PM
  • That's how I publish as well.  It is definitely the best method in my opinion. 

    To clarify for Infopath_girl (in case you're not sure what Clayton is referring to):  You can publish your form as a "Site Content Type" instead of directly to a form library.  When you publish as a site content type you can store the form templates in a library of their own.  Turn on versioning of that form library you store your forms into and you have a copy of each published version accessible to you, and very easy to revert back to the previous version. 

    To use that form template, you then need to allow management of content types in the form library you wish to actually use the form on.  Then add an existing content type (your form published as a site content type).  You can also then modify which content types are available on your "New" button and which is the default. 

    Friday, March 25, 2011 8:19 PM
  • Melli, that is not what I was referring to.  I don't do it that way.  When you publish, you are prompted to save, and I always save straight to a doc lib.  I do not publish as content types, because that causes many more issues with promoted properties, but it's certainly an available option for those who prefer it.

    The difference is that my templates are stored in the Forms folder of the form library, and I have a copy of the template in a separate doc lib for versioning.  With content types, the file in the external doc lib IS the template that all users reach out to when opening a form.  That's not what I like to happen - I like my template to be untouched and stored as a backup.


    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    Wednesday, March 30, 2011 8:00 AM
  • Hi Clay,

    I think it depends on the form's level of complexity as well as the outlook of needed changes.  The method you wrote above works well for my basic forms that I only foresee minor changes to the functionality.  However, in any of the forms that I use to push information to Microsoft Dynamics things get a little complex.  And there might be a need down the road to alter the actual structure of the data source within the form.  When the form gets re-worked with a new datasource, the existing completed forms become incompatible with the new form template and can no longer be opened.  (For instance I changed a form that a had a SQL database as the main datasource - removed the database datasource and just used web services to control where the data goes)

    That being said, using the method I mentioned as a site content type I am able to have the multiple form templates still active in my form library -  the old versions are there, but not available for use as a New form.  Is there a way using the method you described to have multiple form templates in one library? 

    Wednesday, March 30, 2011 12:45 PM
  • I can assure you my forms are far from "basic."  I add and change data sources all the time.  That's not related to site content type vs. library publishing.  I would not create a form directly tied to a DB schema, because I only build browser forms and never connect directly to the DB.  If there is a case where I need multiple content types in one form library, then I have to go that route, but I highly prefer not to.  Either way, that has nothing to do with what I said above when explaining how I manage my form templates in a doc lib (without having to use content type publishing).

    I can push data to Dynamics or anything else without it being a content type form, and I can change the data sources as many times as I want without breaking any schema.  I can also alter the data structure of the form without breaking previous forms.  They do not become incompatible.  I'm afraid what you mentioned is not typical and should not be how it works.  You should always be able to add to your schema and remain compatible with older forms unless maybe it's tied directly to the schmea of a data source, which I don't ever do.

    No, of course you can't have multiple form templates in one library using this method, but I can't tell you the last time I built a solution that required it, and that wasn't the topic that led us to this point.  If I have SEPARATE form templates needed in ONE form library, then I use content types.  I do NOT use content types so that I can have multiple versions of the same form template in one form library.  To me, that's poor planning and execution if I have to do that unless it's the main data source that changes, which hasn't happened to me in the last 3 years..


    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force

    Wednesday, March 30, 2011 2:06 PM
  • I didn't mean your forms were basic at all, I know they're not - in my opinion your the most knowledgeable person there is when it comes to InfoPath & SharePoint that I have come across.  I'm just intrigued by your method and I'm trying to figure out how I can better enhance my methods.  My first 'real' InfoPath solution started out as a database form instead of using web services which is where I ran into the incompatibility upon changing the datasource.  Since then I've been "nervous" about changing the datasource in my existing forms.  But, it's comforting to hear you say that it shouldn't break compatibility when I change the datasource structure of my forms that are not tied to databases. 

    I highly respect your opinion and anytime I question your methods I'm doing so that I can better understand it and apply it in my situations.  I don't know if people thank you enough for your input on these forums - a lot of people out there would be lost if you didn't take the time to be on here, so thank you.

    Wednesday, March 30, 2011 2:18 PM
  • //I don't know if people thank you enough for your input on these forums - a lot of people out there would be lost if you didn't take the time to be on here, so thank you.//

    Very true. I am new to Infopath and this forum. I see a lotttttt of reply/help/answer's to the question-issue's from both of you. Nice work. THANKS A LOT Clayton Cobb and Melli111.

    Wednesday, April 6, 2011 3:06 AM