Printing the Display View of an InfoPath List Item Form

Applies To: SharePoint 2010

I’ve written previously about a cool feature in SharePoint 2010 Server Enterprise that allows you to customize list item forms using InfoPath. It’s really simple to do and you can get some pretty cool results in just a couple of minutes. For instance, I posted a while back about how to use SharePoint column validation to validate email addresses and phone numbers. Those are still good techniques, but by using an InfoPath list item form it’s just a validation drop down (you can even do regular expressions) and you’re done!

So the ease of validation, conditional hiding of fields, etc. are all pretty useful. However, the thing I like it most for is the ability to use different InfoPath views to match the list item views. So you can have different columns available when you’re editing than when you’re adding a new item, for instance. I especially like to spruce up the Display form.

(For some quick tips on how to get the different views working check out the top of my old post)

So, let’s say you’ve got a nice looking display form. Users open that thing up and decide to print. There’s no button, so they use the print button in the browser. Generally they’ll end up with some mess that prints all of your branding, usually some of the list behind the modal dialog, and if you’re lucky mixed in there somewhere will be your display form. Obviously, that’s not going to cut it.

So I did some digging and found some examples of people using javascript to print the form and their solutions were pretty intriguing. But I didn’t particularly want to have to apply some javascript to every form or to have to add a content editor to the pages, etc. I wanted something that just worked on existing forms and new ones too. So I did a little research into Ribbon customization and came across this great series by Chris O’Brien.

I put it all together in a solution and put it over on CodePlex as WireBear InfoPath Printer. There’s some stuff about it’s license over there (Free for personal and commercial use, etc.) and the basic installation instructions. It’s super easy to setup since it’s just a standard SharePoint Solution that you globally deploy.

You can find the full source code over on CodePlex. It’s not too complex and I’ll probably explain most of it in the next couple of posts. Bottom line is that it adds a Print button to the Ribbon when viewing list items that use an InfoPath Form:

The final printout only shows the form (No Ribbon, No Header, No Footer, No QuickLaunch, etc.).

The button is added using Custom Action XML that is deployed as a feature in the solution. The XML is targeted to allow the button to only be present when Viewing a List Item using an InfoPath Browser based List Form.

When you click the button, standard JavaScript is executed to find the InfoPath div element on the page and to copy the form’s HTML into a new window (along with all standard CSS/script references already present) and uses the browser’s page printing. Once the print dialog closes, so does the window.

We’ve been using it around here for a while and almost no one even knows it’s a custom solution. It looks like part of the UI and it’s use is immediately understood. So, go get it (It’s free!) and let me know what you think.

SharePoint 2010 Ribbon Weirdness

Applies To: SharePoint 2010

I was recently helping a user with their SharePoint site on their machine and I noticed some weirdness with the ribbon display. The Tab names were all truncated and too small and their User Name (Menu) was not showing in the upper right corner. Obviously, this concerned me.

Some quick searching didn’t turn up anything and I couldn’t reproduce it on my end. Then 2 days later I was helping someone else and they had the same display problems. Checked their version of IE and they were exactly the same (8.0.6001.18702CO)! But I believe the problem can happen with any version of IE 8.

With this new information did another quick search and found this quick article from Microsoft: where they indicate the Zoom feature is causing the problem.

Sure enough, adjusting the zoom back to 100% fixed the display issue. Strangely, IE 8 seemed to be handling zoom levels in increments of 10 just fine (110%, 120%, etc.) but custom zoom levels (like 128%) freaked it out.

This is problematic because it looks like a problem with the site and adjusting your zoom level is as easy as holding the CTRL key while using the middle mouse scroll. I found that I couldn’t reproduce the problem with IE 9. Until we can get everyone upgraded (a major process around here), it’s just a matter of education among our support staff and end users.