HREF directive of a deployed InfoPath 2003 form is too long and upsetting MOSS 2007.

  • 25 September 2008
  • 5 replies
  • 0 views
S
Badge +4

I have two problems.  First the email notifications on our InfoPath client events don't work.  No errors are generated, they just seem to do nothing.  This isn't that big of a deal as we couldn't customize them to do what we wanted anyway, and we couldn't do the same with the Email Notification event either.  For example, we couldn't use Environment Library settings in the message -- we could add them but they would always get removed (which seems like something you would obviously want to do, but perhaps that's just my warped thinking).  Thus we custom coded email notifications using a Default Server event.  No big deal -- the code is fairly trivial and is as flexible as we want it to be.


Anyway, the second problem is as follows.  In the message body of the email notifications is a link to the file generated in the SharePoint form library.  The URL is correct, however when you click on the link an InfoPath Form Services error is generated.  After quite a lot of testing/digging we have tracked the problem down.  We found the following error in the SharePoint logs:


09/24/2008 17:14:34.32  w3wp.exe (0x17A0)                        0x07E8 Windows SharePoint Services    General                        8kh7 High     The specified file or folder name is too long. The URL path for all files and folders must be 260 characters or less (and no more than 128 characters for any single file or folder name in the URL). Please type a shorter file or folder name.


What is causing this is the HREF in the MSO-INFOPATHSOLUTION directive of the form.  This is what the directive looks like:


<?mso-infoPathSolution solutionVersion="1.0.0.2769" productVersion="11.0.6565" PIVersion="1.0.0.0" href="http://tstmoss:37974/sites/Applications/PWR/Requests/Forms/template_-myXSD-2008-09-24T14-01-30.xsn?SaveLocation=http://tstmoss:37974/sites/Applications/PWR/Requests/&amp;Source=http://tstmoss:37974/sites/Applications/PWR/Requests/Forms/AllItems.aspx&amp;OpenIn=PreferClient&amp;NoRedirect=true&amp;XsnLocation=http://tstmoss:37974/sites/Applications/PWR/Requests/Forms/template_-myXSD-2008-09-24T14-01-30.xsn" name="urn:schemas-microsoft-com:office:infopath:Requests:-myXSD-2008-09-24T14-01-30" ?>


We played around and stripped off the XmlLocation of the generated files, put them back in the library and everything worked, including the links in our email notifications. For what it's worth, we found that we could strip all but the URL to the form out of the HREF arttribute and it still worked, so we are not entirely sure what purpose the attributes serve (perhaps they are useful if you use Form Services, which we don't).  We know what some are used for, but again, removing them didn't seem to break anything.


It only affects external links as there is an onClick event on links in the Form Library that calls into SharePoint's Core.js library and performs some magic that is not affected by this.


Anyone know of a workaround?  Is this a known bug?  I haven't found anything in the forums or KB, but I would be surprised if someone else hasn't encountered it.  I am considering writing some code that will rewrite the HREF attribute.  Seems like a gross hack, but it should work.


Cheers.


P.S.  Sorry for the link...The Rich Text Editor doesn't seem to work properly.


(On a side note, I think someone should moderate the Tags...Dear Lord!)

5 replies

G
Badge +5

So, this is a minor point, but...


Have you tried to use the String Table info in your mail events, instead of Environment Library settings?


The Environment Library settings aren't used at runtime, typically, whereas the String Tables are.


 


HTH

S
Badge +4

@Blake: The form library already has the "Open in the client application" option selected.  In fact we went as far as disabling all Form Services features for the site, but hasn't helped... :-(  There's got to be something really stupid we have missed.

S
Badge +4

@Gail: I'll try that, thanks!  However, we I think we will still need to customize the message but I don't remember seeing a way to drop to code.  I'll check...

S
Badge +4

BTW, we also get the same error form the K2 Workspace when selecting "Open" from a work item.  This makes sense seeing as it is an external link to the SharePoint form library.


I have tried going back and forth between "Open in client application" and "Open in browser" and neither seems to make a difference -- it always opens in the client (probably because we disabled Form Services for this application in an attempt to work around the problem).  This appears to be caused by SharePoint because when I open the library in Explorer view and double-click on the template directly I see in the dialog boxes as the form opens the URL to the template and it _doesn't_ contain the additional query parameters as happens when I use the "New" option on the library's toolbar.


I'm not sure when the root cause of the problem is.  It appears to be SharePoint, but I wonder if it has something to do with how BP published the form in the library.  As such, I am not sure if I should open a ticket or not...

S
Badge +4

So we _still_ have this problem on all three of our servers.  It's driving me insane.  I still don't know where the problem actually lies...Does MOSS or K2 append the query string crap to the href attribute URL?


Update:  Here is my hack-n-slash fix to the problem.  Call this method from the form's OnLoad() event.


/// <summary>


/// Remove all query string parameters from the href "attribute" of the


/// mso-infoPathSolution processing directive. The query string


/// parameters causes problems with Form Services as they make the URL


/// too long. If you don't use Form Services, this is safe to do.


/// </summary>


private void FixMsoInfoPathSolutionHref()


{


IXMLDOMProcessingInstruction msoProcessingInstruction =


(

IXMLDOMProcessingInstruction)thisXDocument.DOM.selectSingleNode("processing-instruction("mso-infoPathSolution")");


// hrefStartPosition: Find the beginning of the href attribute


int hrefStartPosition = msoProcessingInstruction.text.IndexOf("href=") + 5;


if (hrefStartPosition > -1)


// Found the href "attribute"


{


// questionMarkPosition: Find the "?" in the href attribute.


int questionMarkPosition = msoProcessingInstruction.text.IndexOf("?", hrefStartPosition);


if (questionMarkPosition > -1)


// Found the question mark that delimits the query string parameters from the URL


{


// hrefEndPosition: Position of hhe closing quote of the


// href attribute.


int hrefEndPosition = msoProcessingInstruction.text.IndexOf(""", questionMarkPosition);


// Build the PI value (removing the unwanted query string


// paramaters from the href attribute).


StringBuilder newHref = new StringBuilder();


newHref.Append(msoProcessingInstruction.text.Substring(0, questionMarkPosition));


newHref.Append(msoProcessingInstruction.text.Substring(hrefEndPosition, msoProcessingInstruction.text.Length - hrefEndPosition));


msoProcessingInstruction.text = newHref.ToString();


}


}


}

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings