Independant forms? - InfoPath Dev
in

InfoPath Dev

Independant forms?

Last post 02-01-2008 08:55 AM by djay. 6 replies.
Page 1 of 1 (7 items)
Sort Posts: Previous Next
  • 08-01-2006 07:29 AM

    Independant forms?

    Good morning all!!!

    I am here once again trying to figure out this potentially incredible application called InfoPath.

    I really like the features that come with InfoPath, but am not crazy how it is linked to a master form. I was wondering if there was a way to have a form perform independantly. So, if I have one of my coworkers open up a form and do a "save as" to it, then I go and make a change to the master, then the changes will not effect the forms opened and created from prior to the changes.

    I know this may sound crazy to me, but I am really liking the functionality of the form, and all the options you have to create views within a form especially. I don't need these forms to reference prior form or any access databases. I just want to know if there is a way that each form will be an independent of themselves.

    I really hope there is a way to do this and I appreciates everyones help. Thank you for all yours patience and have a great day!!!
  • 08-02-2006 05:24 AM In reply to

    Hello
    What do you mean by a Master Form? Template?
    Yes Infopath forms can function independently. If you make the changes to the Template you can publish that in Different form libraries.

    Hope I did understand your point correctly
    Kalyan G Reddy
    Infopath MVP 2007 and 2008
  • 08-02-2006 03:29 PM In reply to

    Hey,

    InfoPath is and is not like other Electronic Form packages (ie., F3 Fill, Jetform, Delrina, Adobe and Accelio).

    Like the other E-Form packages, the data file is separate from the template.

    Unlike the other E-Form packages, when you revise the template (especially adding new or deleting fields from the datasource) older data will no longer understand the template if published in the same location unless you write an upgrade.xsl or some upgrade code.

    In other words, Microsoft is requiring the developer to write the functionality of how to map the old data to the new version of the template. This is not how prior E-Forms packages operated.

    If you look at the InfoPath SDK, Microsoft states "When you design a form, Microsoft Office InfoPath 2003 assumes that the form's data source is in it's final state. InfoPath doesn't adapt to changes in the form's data source. "

    To give Microsoft a little credit, that makes sense if your forms are being driven by Databases and/or web services. However, if you deal with 400+ InfoPath forms in an Enterprise envornment for users in Field Sales, Internationally as all USA states where only a few of the 400+ forms are database driven....this philosophy is absurd!

    To lessen some of the impact, we have decided to add a task pane to the older version of form informing the user that the form has been replaced by a newer version. We republish the "task pane" version of the form into the same Form Library in sharepoint. This allows for any workflow data to complete its course.

    Then we copy the new version of the form to the Sharepoint library, go into Modify Columns and settings and change the template name to xyz_yyyymmdd.xsn and republish it to the same library.

    In Sharepoint Form libraries, whatever the file name in the template section of modify columns and settings is - is what the publishing wizard uses when publishing a form via InfoPath to Sharepoint.

    It is not as clean as the other E-Forms packages which understand the old data files regardless of how many changes occur to the template, but it is the best we could manage when only 1 person is maintaining 400+ electronic forms.

    Just my 2 cents worth,
    Mary
  • 08-02-2006 03:52 PM In reply to

    It is always best to have the schema of a form finalized before you start using it in a production environment, but changes are often inevitable. For the future forms to properly handle these schema changes InfoPath creates an upgrade.xsl automatically that should convert old XML files into the new schema. However, this can only add nodes and will not delete or rearrange them. Therefore, if the only schema changes you ever make to the "Master Form" as you call it are additions of nodes to the schema, then the upgrade.xsl should be all you ever need.

    If you decide to delete or rearrange nodes, then you will be forced to write code so that the old XML files are converted upon opening.
    Matt Faus / Microsoft InfoPath MVP
    Qdabra® Software / Streamline data gathering to turn process into knowledge
  • 01-31-2008 07:37 PM In reply to

    • djay
    • Top 500 Contributor
    • Joined on 06-06-2006
    • Posts 35

    I'm working on implementing Mary's system.

    But I want to automaticly detect (when a form opens) if it is using the latest template or not.  And if it is using an old template and it is not signed it should automaticly upgrade...

    But I am stuck just trying to find what the latest template on the SharePoint server is.  The only way I have found to get close is to use the Lists.asmx web service and use the GetListContentTypes method.  But the returned data does not have the template URL.  The only identifyer is the ID, which looks like a SharePoint generated ID which is not saved in the individual form's XML.

     The only idea I've got at this point is to open the template on the SharePoint server, and check if it is the same as the currently open form from within InfoPath.  But that is hacktastic at best.  Or manually update the old template to identify it as old, but I'm way too lazy for that.  Does anyone have any better suggestions?

  • 02-01-2008 12:33 AM In reply to

    Hi DJay,

    Just write an OnVersionUpgrade event handler in the latest XSN (using code). When the version upgrade event fires (on load) it means the form is from an old version and has to be upgraded. Then, you can insert the missing fields, or modify the XML before it validates the form. Here's an example from the SDK:

    function XDocument::OnVersionUpgrade(eventObj)
    {
       if (!XDocument.DOM.selectSingleNode("/Customers/CustomerInfo/EmailAddress"))
       {
          try
          {
             // Create the new element.
             var objItemNode = XDocument.DOM.selectSingleNode("/Customers/CustomerInfo")
                .ownerDocument.createElement("EmailAddress");

             // Add the new <item> element to the XML document as a
             // child of the <order> element.
             XDocument.DOM.selectSingleNode("/Customers/CustomerInfo")
                .appendChild(objItemNode);
             eventObj.ReturnStatus=true;
          }
          catch(ex)
          {
             XDocument.UI.Alert("There was an error inserting the " +
                "<EmailAddress> node.\nDescription: " + ex.description);
             eventObj.ReturnStatus=false;
          }
       }
    }

    You can check for the signature section in the schema to determine whether it is signed or not.  

    There was another related thread on this last week: http://www.infopathdev.com/forums/p/7106/25973.aspx#25973.

    Patrick Halstead
    Project Manager at Qdabra
  • 02-01-2008 08:55 AM In reply to

    • djay
    • Top 500 Contributor
    • Joined on 06-06-2006
    • Posts 35

    Thanks for the reply Pat, but that won't work.  When I update the template I will save it to the SharePoint server as a different name.  This is so that, if it is signed, the form will open properly with the old template (see this thread for why).  So the form will be opened from a template that doesn't know it is old.  SharePoint is the only object that knows what the latest template is.  But looking at your other post you already know that.

    It won't be hard to setup template version control, if I knew what the latest version is.  There are many SharePoint web services, and I know the data is in there somewhere...I'm just hoping someone knows how I can get to it.  If no one knows I will probobly end up throwing the value up on a SQL server somewhere and manually change it.  But that isn't very elegant.

Page 1 of 1 (7 items)
Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.