IPrintJobItem Properties

Discussions related to SoftPro Select user interface development.

Moderator: Phil Barton

roteague
Posts: 292
Joined: Thu Sep 25, 2008 4:49 pm
Location: Honolulu, Hawaii

IPrintJobItem Properties

Post by roteague »

I'm using the properties bag to get the name of the document being printed. To do that I use the IPrintJobItem Property "DocReportName". However, it seems that this property doesn't exist if the user prints multiple documents at a time. I'm looking to grab the name as a means of being able to upload my document to our internal document management system, so the name is pretty important.

It does look like I can grab the OriginalItems property bag from the IPrintJob object instead of using the Items in the PrintJob, to get the name. It seems like these are not standard between print jobs, and I'm wondering how complex this is going to make the process. Wouldn't it be easier to have some "basic" properties for each PrintJob Item?

Thanks,
Robert
Mark McKenna

Re: IPrintJobItem Properties

Post by Mark McKenna »

What you're seeing is our collation process combining documents such that they no longer represent a single ReadyDoc. When documents are combined, they lose some of their individuality.

For example, when 2 documents are printed:
1. Each document is rendered individually and added to the print job as separate items (you see them under the "OriginalItems" property, as noted).
2. The print job is executed along the pipeline.
3. There is a pipeline handler that executes early in the sequence that collates/combines job items into new job items, based on their grouping characteristics. If A and B are combined into C, then the print job items for A and B are removed from the job, and a new one is added to the job that represents C. The properties for C's new print job item are determined as the intersection of the properties for A and B. Thus, C does not have a DocReportName property because A and B did not share the same name. Only those properties with values shared by both A and B are retained into C (this might account for some of the variability you're seeing).

Note that the OriginalItems collection is never changed (by us, at least) once the print job hits the pipeline.

The collation process is actually pretty complex. It uses each document's Group characteristic, along with the business object instance for which it is being generated, to sort documents into collation buckets. Then it performs an additional collation pass of documents that have no Group assignment. If many documents end up getting collated into 1 (which is often the case if you don't use Group assignments), you can imagine how small the intersection set ends up being for any properties to survive.
It seems like these are not standard between print jobs
When a document is added as a print job item to a print job, it will always have the same DocReportName inside the job's OriginalItems collection. The name is simply what you see in the documents tree.
roteague
Posts: 292
Joined: Thu Sep 25, 2008 4:49 pm
Location: Honolulu, Hawaii

Re: IPrintJobItem Properties

Post by roteague »

Thanks Mark. It sounds like I'll be safe using the OriginalItems for the various items that I need (ordernumber, docname, etc.).
Robert
Shevy
Posts: 48
Joined: Tue Dec 23, 2008 12:21 pm

Re: IPrintJobItem Properties

Post by Shevy »

Is there a way to retrieve the Word Doc name of the document being printed? where can I see a list of all the "OriginalItems" properties?
Mark McKenna

Re: IPrintJobItem Properties

Post by Mark McKenna »

Currently, the original file name of the document is not exposed by the print job item. There is a property named "DocReportName", but that exposes the title of the document, which is likely not what you want.

All available properties exposed through the IPrintJob and IPrintJobItem interfaces can be discovered by looking at the keys of the associated Properties dictionary itself (a string->object map). Just keep in mind that some keys are not always present, and some that are present may have null values, depending on the particular state of the item represented (e.g. a report does not have any keys related to primary context).

Code: Select all

IPrintJobItem item = printJob.Items.ElementAt( 0 );
string[] keys = item.Properties.Keys.ToArray( );
As for IPrintJob.OriginalItems, it simply provides an enumerator over the original collection of print job items, when the job first hit the printing pipeline. It does not change as the job progresses through the pipeline. Contrast that with IPrintJob.Items, which provides an enumerator over the current collection of print job items in the job. The latter is volatile, because the job morphs as it progresses through the pipeline (e.g. merging, collating, etc.). In general, the properties available are the same, but in many cases, the properties that happen to be defined are not.
Shevy
Posts: 48
Joined: Tue Dec 23, 2008 12:21 pm

Re: IPrintJobItem Properties

Post by Shevy »

Thanks, however ReportDocName wont help me since I may have a few with the same ReportDocName.
What I need is a unique identification for the document, maybe by folder and docReportName?
Any ideas?
Thank you.
Mark McKenna

Re: IPrintJobItem Properties

Post by Mark McKenna »

DocReportId is one of the properties exposed by the print job item. It is the unique identifier of the document/report it represents. Here again, keep in mind that this is one of those volatile properties that will exist on the original print job item, but if that item becomes subject to any collation/merging as the job progresses along the pipeline, the resultant/new print job item will no longer define the DocReportId property because it will not represent a single document/report (rather, it will represent all the document/reports that were merged together).
Shevy
Posts: 48
Joined: Tue Dec 23, 2008 12:21 pm

Re: IPrintJobItem Properties

Post by Shevy »

Thank you.
How do I reference that? I am looping through as follows:
For Each item As IPrintJobItem In printJob.OriginalItems.
Can you show me how my loop should look to show the DocreportID?
Mark McKenna

Re: IPrintJobItem Properties

Post by Mark McKenna »

We would typically do something like this:

Code: Select all

foreach ( PrintJobItem item in printJob.OriginalItems )
{
	object obj;
	item.Properties.TryGetValue( "DocReportId", out obj );
	if ( obj != null )
	{
		Guid docReportId = (Guid)obj;
		// do something
	}
}
Both the IPrintJob and the IPrintJobItem interfaces expose a volatile set of ancillary properties in this way.
Shevy
Posts: 48
Joined: Tue Dec 23, 2008 12:21 pm

Re: IPrintJobItem Properties

Post by Shevy »

What does the GUID represent? Is there a way for me to know that number before I print?
Let me explain what I need:
- I need to have a unique way to identify the word documents so that at the point that it is being printed I know exactly which document is being printed. If I just use the DocReportName, there can be duplicates, since multiple word documents may have the same description. However if I am able to get the doc Name or ID that would work.
Thank you for all your help with this.
Post Reply