Posted at: 3:08 PM on 20 August 2010 by Muhimbi
Next up in our series about new features in the PDF Converter for SharePoint 4.0 and PDF Converter Services, we’ll showcase some of the new Export to PDF View Selection capabilities of our InfoPath converter.
Being able to select which views to export is very useful as quite often different views are used for exporting a form to PDF. Sometimes using the Print View is good enough, but other times you need to export a different view or multiple views to PDF format. There are even occasions where different views are exported depending on the state of the data entered in the form.
As always, the best way to illustrate this is by example.
Use a special view for exporting to PDF
In this scenario we have an Employee Review form with the following 3 views:
- Data entry view: A view used for populating data using the InfoPath client or Forms Services. This is the default view.
- Print View: A special view that is optimised for printing to a network laser printer. This is specified as View 1’s Print View.
- PDF Export view: A separate view that is used to export the InfoPath form to PDF format as it contains some information that should only show up in exported PDF files.
As View 1 is the default view and View 2 is the Print View for View 1, under normal circumstance the 2nd view is used for exporting to PDF. However, we want to use View 3 for this purpose. We can achieve this by starting the name of View 3 with “_MuhimbiView”. The Muhimbi PDF Converter will automatically detect all views that start with this name, export them all and merge them together into a single PDF file. Naturally these views can be hidden from the end user by marking them as such.
This is a great solution if you know beforehand that you will always be exporting the same view(s) to PDF format.
Determine at runtime which views to export
The previous solution, using view names that start with “_MuhimbiView”, works great. However, sometimes you need to export a different view depending on the state of the data.
For example, our Expense Claim form consists of the following Views:
- Data Entry View 1: Used by the employee to report expenses.
- Data Entry View 2: Used by the manager to add comments and additional information.
- PDF Export View 1: The view that is used to export the form to PDF format before the manager has reviewed the form.
- PDF Export View 2: The view that is used to export the form to PDF format after the manager has reviewed the form.
OK, so how are we going to deal with this? Well, here comes the Muhimbi PDF Converter to the rescue! By adding a (hidden) text box named “_MuhimbiViews” (case sensitive) to any of the views and populating it with the name of one or more comma separated view names, the Muhimbi PDF Converter will automatically pick up these names and export them to PDF format. If multiple views are specified then they are automatically concatenated together.
In addition to adding the “_MuhimbiViews” text field to the form, all the developer of the form needs to do is to add a little bit of logic to the Submit event of the 2 data entry views that specify the correct view name to export in the “_MuhimbiViews” field.
View prioritisation rules
To determine which view or views to export, the Muhimbi PDF Converter uses the following prioritisation rules:
- Version 4.1 and up: When using the web services interface, any ConversionViews specified in the ConverterSpecificSettings property will be converted. If this property is not set then the following rules will be used to determine which views to convert to PDF.
- If a field named “_MuhimbiViews” is found anywhere in the InfoPath form then the content of this field is used to determine which views to export.
- If the previous field does not exist, is empty or the specified view name does not exist then the converter looks at all view names that start with “_MuhimbiView”.
- If none of the previous options apply then the view marked as the Default View is exported.
Regardless of how a view or views are selected for export, if the selected view has a Print View specified than that view is given priority.
Do not use Muhimbi’s View selection features in combination with InfoPath's 'Print multiple views' facility. The latter is given priority when converting to PDF.
When the final PDF file is assembled then all selected views are included first, followed by any converted attachments.
In summary, the new version of the PDF Converter adds flexible View selection features to make the life of InfoPath developers easier. As always, upgrades are completely free. Don’t hesitate to leave a comment below if you have any questions or contact us to discuss anything related to our products.
.
Labels: Articles, InfoPath, News, pdf, PDF Converter, PDF Converter Services, Products

8 Comments:
Hi, now i'm using trial Muhimbi convert pdf. And this feature is very good for me to select view infopath when convert. I need to test before buy your product. I want to know when this feature will be release.. send info for me. minhtritp@yahoo.com
By
MTV, At
23 August, 2010 13:25
Hi, i'm also using trial Muhimbi convert pdf. This feature would be very handy for me to select view infopath when convert. I need to test before buy your product. I want to know when this feature will be release.. send info for me
thomas.griffiths@biz-ict.com
By
Thomas, At
06 October, 2010 16:58
It will be out in the next few weeks, we are finalising documentation at the moment. Your company already has access tot he beta version.
By
Muhimbi, At
06 October, 2010 17:28
I have a Infopath form with ink picture control.
I am not able to convert to pdf. Rest of the forms work fine.
Any Idea of this issue.
By
Atul Verma, At
01 July, 2011 09:52
Hello Atul,
Please send a copy of your XSN and XML file to support@muhimbi.com for further investigation.
Thanks.
By
Muhimbi, At
03 July, 2011 15:58
I'm having exactly the same problem with a form with Ink Controls.
Is there any resolution?
By
Stuart Pittwood, At
27 July, 2011 13:07
Hi Stuart,
Please contact us on support@muhimbi.com as we have a patch available.
By
Muhimbi, At
27 July, 2011 13:38
The problem with Ink Controls has been resolved by the customer. It is related to the Ink controls not being deployed by default on Windows Server 2008 R2. Installing the "Ink & Handwriting" Windows Feature, part of the "Desktop Experience" on the server that runs the Muhimbi Conversion Service solves the problem.
By
Muhimbi, At
28 July, 2011 11:32
Post a Comment
Subscribe to Post Comments [Atom]
Links to this post:
Create a Link