Tuesday, October 23, 2007

The following helper class demonstrates a few techniques that allow documents to be uploaded to a SharePoint document library programmatically without using the API or a custom web service. You don't need to specify a document library name, and it will create any folders specified in the URL as required. File meta data will be updated if any properties are passed.

To use this code add a reference to the SharePoint Lists service (/_vti_bin/Lists.asmx) and name it ‘ListsService’. The code was written against MOSS 2007.

To download files use the GetItem method of the SharePoint Copy service (/_vti_bin/Copy.asmx). While it’s possible to upload files using the CopyIntoItems method of this service, it won’t create folders as needed, and you’d probably want to remove the copy link that is created.

It's also possible to use Front Page Server Extensions and RPC calls to upload files with meta data - the code for which is a bit more efficient as it doesn't require web service calls. Using RPC calls is covered in Part II.

Update: You can download a comprehensive c# class library to automate RPC calls - including uploading files to a SharePoint document library. See this blog post for more information.

Thursday, October 18, 2007

In Part I and Part II I posted about the problem caused by the static size of the InfoPath Forms Services multi-line text box. Generally the workaround is to use the rich text control, and in fact this is the workaround suggested by Microsoft for a separate issue - KB931426 - whereby the malformed content of a multi-line text box (actually just any old words that include a space) can cause Forms Services to lose it when the form has been designed to be submitted via email.

You'll know something's up when you get the message "There has been an error while processing the form." returned to the browser, along with "Exception Message: Reference to undeclared entity 'nbsp'" or "System.Xml.XmlException: Reference to undeclared entity 'nbsp'" in the diagnostic log.

So the suggested workaround is to change your schema and use the rich edit control. If you'd really rather not do this, there is actually an alternative method. If the text box doesn't contain spaces - no issue, so the workaround is to strip the text box of spaces, replace it with something that looks like a space (ASCII 160 - the code for the HTML non-breaking space character '&nbsp;'), submit the form using your email data connection, then reverse out the character replacement.

Easy enough. You can even do all this through rules. This post on the InfoPath Team Blog demonstrates a method for using a secondary data source to reference non printable characters (in this case to insert carriage return / line feed characters). First up, you'll want to add a resource file with the following content (the only attribute that you'll actually be using is the nbsp - the others are just for fun)...

<?xmlversion="1.0" encoding="UTF-8"?>

<characterscr="&#xD;" lf="&#xA;" crlf="&#xD;&#xA;" nbsp="&#xA0;" />

Next, edit the form's submit options to submit using custom rules and add a rule that has a series of actions that first strips the spaces, e.g. set each multi-line text box field's value with a formula like the following, using the technique from the Team Blog post:

translate(address, " ", @nbsp)

Follow these actions with an action that submits the form.

Lastly, add however many "Set a field's value" actions as required to reverse out the character replacement, e.g. using a formula like:

Wednesday, October 17, 2007

In Part I I posted an example that demonstrated dynamic resizing (past a minimum height) - giving multiline text box resizing functionality (in IE7 at least) similar to the rich edit text box. So the next question is, how difficult would it be to modify the javascript that renders InfoPath forms on the client to get around this print clipping problem? Well unfortunately although it might not be that hard, it's unlikely you're going to want to try it. According to this post by Liam Cleary (a SharePoint MVP) you shouldn't really modify server files - presumably because of the EULA or the risk of breaking all the SharePoint web applications on your IIS server.

Any other options? Well, you might think that using an expression box (which can be set to expand to show all text) on a print view could be a way to get around the problem of overflow text being clipped. There's only one issue - the expression box in all probability renders as an html <span> element - so any carriage return / line feeds are going to be ignored. It looks like any html is also escaped, so again, aside from messing with the rendering javascript (replacing \r\n with <br /> say), it's probably not going to give you the result you're after.

It looks like unless an update is released, the rich text box is it as far as text edit controls that will resize dynamically on a browser form. Form designers not wanting to use this control who want all text to be visible on screen or in print will have to make sure that control is sufficiently large at design time.

All of that said, the TextBox Render function is right there in plain text for everyone to see, so if I had to take a bit of a guess as to how the SharePoint developers might go about creating a quick fix for this problem in the future - one scenario could see code along the lines of that at the bottom of this post.

In Part III I’ll address another issue with the maligned text box and browser-enabled forms - KB931426. The Microsoft workaround is to use the rich text box, but for people who want to avoid this there is an alternative workaround.

Friday, October 12, 2007

When using web browser enabled (InfoPath Forms Services) InfoPath templates that have been published to a SharePoint 2007 site, multi-line textboxes will only display with the height that was specified at design time. If the text box contains text that overflows the design size of the control, a scrollbar appears, and only the visible portion will print.

The alternative is the rich textbox control, however this requires a data source element of the xhtml data type, which may not always be appropriate (e.g. users can copy any html into the field), or available (e.g. when using 3rd party schemas). Fields using the rich textbox control are not editable in browsers other that Microsoft IE. In addition, using this data type can lead to complications when using forms for workflow related tasks. Xhtml data will not serialize to binary by default, requiring a custom serialization routine.

Despite these potential drawbacks, if you want your multi-line text to always print without clipping, you're pretty much going to be stuck with xhtml. What would be great is if the multi-line dynamically expanded as it can be made to do in the InfoPath client. It's a bit of a mystery why Microsoft didn't include this sort of functionality in the Forms Services rendering - after all the rich text box has this functionality and works well. The code below demonstrates how such functionality might work (in IE). In Part II, I'll show that it might be possible to modify the javascript that renders the InfoPath forms on the client to provide similar functionality, and why you probably won't want to do this.