July 2004 - Posts - Patrick Halstead
in

InfoPath Dev

Patrick Halstead

July 2004 - Posts

  • SharePoint Columns Don't Use Real XPaths to Get Their Data

    Suppose you have a schema with the following structure:

    myfields
        ns1:coolDocument
            coolField
        ns2:coolDocument
            coolField

    When you save your form to SharePoint, if you select to promote both coolField entries, then the promotion will fail for the 2nd entry (actually, it will read the first entry instead of the second).

    The reason this happens is because SharePoint XML parser doesn't support namespaces, so the pseudo xpaths are actually just /myFields/coolDocument/coolField, i.e. there's no ns1: prefix. That means that the second column will extract the value from the first coolField.

    More details: the SharePoint XML parser completely ignores the namespaces and has no support for XPath. This is why the XFP uses the name “node“ for the attribute versus XPath. It is not really an XPath but rather a list of element names separated by slashes.

    WORKAROUND:

    Don't use or promote elements with the same name if they have different namespaces.

  • IsReadOnly Doesn't Always Work for Attached Forms

    If your form contains logic that checks to see if it is read-only (thisXDocument.IsReadOnly), there is an issue with Outlook where InfoPath will report false positives depending on your Outlook cache settings.

    Most of the time, it doesn't make sense to call IsReadOnly for an attachment, so the workaround would be to determine if your code is an attachment or not and only use IsReadOnly when it is opened from a shared website or local folder.

    Here's some C# code to determine if your form is an attachment or not:

    private string getFormPath()
    {
        string sFormUri = thisXDocument.URI;
        int iPosition = sFormUri.LastIndexOf("/");

        // if path is outlook file cache, this will return ""
        if (-1 != iPosition)
            // Just return path
            return sFormUri.Substring(0, iPosition + 1);
        else
            return "";
    }

    private string getSharePointFolder()
    {
        string sUri = thisXDocument.Solution.URI;
        int iPosition = sUri.LastIndexOf("/Forms/");
     
        return -1 != iPosition ? sUri.Substring(0, iPosition + 1) : "";
    }
     
    _fOpenedLocally = (0 != string.Compare(getFormPath(), getSharePointFolder()));

  • SharePoint List Adapter Only Returns 100 Items

    SharePoint list adapters are really cool because they give you the ability to query a data source that is easily editable via Internet Explorer (as opposed to a SQL database which requires more work to build a UI around data manipulation).

    InfoPath relies on getListData web service to return the items from a SharePoint list. Unfortunately, that web service only returns the items in the view.

    This is bad since it means that one must modify the view on SharePoint to workaround the default limit of 100 items and that requires different permissions than just querying the list (Contributor vs. Reader).

    This is not fixed in the release bits of SharePoint. InfoPath can't fix it. 

    WORKAROUND:

    Just to bump up the default settings for the view, but how high should the number be set?  On ShP, go to Modify Settings and Columns. Click on the default view. Scroll to bottom where it says item limits. Click to expand, and set from 100 (default) to whatever.

  • Deploying Managed Code Solutions: Two Methods

    You can't use restricted mode to deploy a managed code (C# or VB.NET) solution in email because InfoPath doesn't allow managed code to run in restricted mode (for good reasons).

    You have 2 options:

    • Sign the xsn using a digital certificate
      • Pros: the future is digital certificates
      • Pros: publishURL is not removed
      • Con: it will cost you some money to buy one (if you don't already have one)
      • Con: if the publisher isn't trusted by windows you have to jump through more hoops
    • Create an MSI using RegForm
      • Pros: easy to do - check it out in the InfoPath SDK
      • Pros: easy to install - no hoops to jump through
      • Cons: removes the publishURL

    Q: What's the publishURL?
    A: The publishURL is an attribute in the InfoPath form template's PI that describes where the form lives. It is set when you publish to a location.

    Q: Why does RegForm remove it?
    A: Couple reasons. One: RegForm was created in InfoPath 2003 version 1 as a means to create a URN-based solution (i.e. a solution that is based on it's name, not a location). Two: for security reasons, publishURLs need to be removed before a solution can be “installed“ on a machine. Note: installation is different thing than simply caching as it allows the solution to run Full Trust.

    Q: Who cares about publishURL?
    A: Ah, yes. The meat of the matter. If you want to create a single form that submits requests from outside (via e-mail) but implements workflow for inside (a corporate network) then your xml forms will have to have the publishURL so that when an internal user opens them it redirects to the internal website where the workflow happens.

    Q: Why do it all in one solution?
    A: Good point. You can implement the split outside request / inside workflow using two solutions but that would require hardcoding the location of the internal form library in a secondary data source, and it will be more work.

  • NewFromSolution Does Not Cache Forms Correctly

    Steps to repro:

    1. Create a jscript Form A with the following code attached to a button OnClick event handler:

      var oXDoc = Application.XDocuments.NewFromSolutionWithData(XDocument.DOM.documentElement, sSharePointTemplate, 1);


      where sSharePointTemplate refers to the xsn in your form library, for example:

      http://sharepoint.company.com/name/Forms/template.xsn


    2. Create a managed code Form B using the same schema as in form A with a button that loads a file from the form library. For example:

      thisApplication.XDocuments.Open(sForm, (int)XdDocumentVersionMode.xdCanOpenInReadOnlyMode);


      where sForm points to the location of the file, for example:

      http://sharepoint.company.com/name/foo.xml


    3. Publish Form B to the form library that you use for the sSharePointTemplate parameter above. I.e., publish to:

      http://sharepoint.company.com/name/


    4. Open Form A and click the button to run the code.
    5. Form B should open automatically. Click on the button.

    Result: error. This is the same error that is documented at: http://support.microsoft.com/default.aspx?scid=kb;en-us;823436

    However, I think it's a different problem.

    Q: Why do I care about this scenario?
    A: If you have a split solution to handle workflow between offline forms and online collaboration, you might want to do this since RegForm removes the publishURL and digital certificates are costly to install (see previous post).

    Q: How do I workaround this problem?
    A: The easiest thing is to navigate to Form B's form library and click “Fill Out This Form” before running Form A. Then Form B is cached with the correct settings.

Copyright © 2003-2019 Qdabra Software. All rights reserved.
View our Terms of Use.