Printing Pipeline Targets

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

Printing Pipeline Targets

Post by roteague »

Is there any way to change the print target to set a specific printer? When I look at the PrintJobProperty.Target while printing, it only contains the value "Printer".

We would like to be able to specify what printer to use based upon the document type, and not leave it up to the user to select the proper one.

Thanks,
Robert
Mark McKenna

Re: Printing Pipeline Targets

Post by Mark McKenna »

Generally, you could accomplish something like this by replacing our printer dispatch handler with your own. Ours simply looks to see if 'Printer' is one of the targets, and if so, it handles it by displaying a standard PrintDialog to obtain the PrinterSettings, and then prints each print job item's PDF file directly to that printer. Assuming there is enough information in the print job with which to make your printer choice, you could do that work inside your custom dispatch handler and then show the same dialog with that printer selected by default. However, I see that our PDF printing classes are currently internal so for this option to work in a current version of Select you would need to load and print those PDFs directly using third party software.

Note that you would have to replace our handler completely, and not just insert yours to execute before ours, because currently you can't remove a target to prevent a downstream handler from acknowledging it without adversely affecting the auditing functionality ("Document A was printed on 12/3/2008 by User B") which in plugged in to the very end of the pipeline and references those targets. For the same reason, you can't cleverly halt the pipeline by returning true after successfully printing from your handler either.

Ideally, our default Printer Dispatch Handler would allow for the print job to "carry" a PrinterSettings object that, if present, would be used automatically/silently. If this were the case, you would simply insert a custom dispatch handler to run before ours that does the printer selection work (including showing the dialog), and then adds the resultant PrinterSettings object to the print job. I'll add that as an item to consider on our end.
roteague
Posts: 292
Joined: Thu Sep 25, 2008 4:49 pm
Location: Honolulu, Hawaii

Re: Printing Pipeline Targets

Post by roteague »

Mark McKenna wrote:Ideally, our default Printer Dispatch Handler would allow for the print job to "carry" a PrinterSettings object that, if present, would be used automatically/silently. If this were the case, you would simply insert a custom dispatch handler to run before ours that does the printer selection work (including showing the dialog), and then adds the resultant PrinterSettings object to the print job. I'll add that as an item to consider on our end.
Thanks Mark, I'll kick this up the pipeline here to see how Project Management wants to handle this. We would prefer not to replace SoftPro's built in functionality. What we are concerned about is that certain types of documents need to printed on special types of paper, which is only loaded on very specific printers.
Robert
Mark McKenna

Re: Printing Pipeline Targets

Post by Mark McKenna »

One thing you could try is to create a custom dispatch handler and plug it in to the pipeline such that it executes immediately before our default printer dispatch handler. In this new handler class, you could evaluate the print job (or its items) and determine then and there what the default printer ought to be for the job. Using Win32 P/Invoke or WMI as appropriate, you could set the default printer before returning from your handler. Our handler would then execute normally, but your choice would show up as the default in our dialog. If you do need to restore the default printer back to what it was prior to it being changed, you would plug another handler in to execute immediately after ours to reverse the process. To communicate between the two you could drop the (old) printer name into the print job's property bag in handler #1 and then grab it in handler #2. You could even use the same handler class to perform both sides and just plug it in to the pipeline twice (such that if the "old printer name" property is not defined, you are in set mode, otherwise you are in restore mode). Note that although you'd be reusing the class definition, these would be two separate instances.
roteague
Posts: 292
Joined: Thu Sep 25, 2008 4:49 pm
Location: Honolulu, Hawaii

Re: Printing Pipeline Targets

Post by roteague »

Great suggestion Mark, I'll take a look at something like that.
Robert
Mark McKenna

Re: Printing Pipeline Targets

Post by Mark McKenna »

I wanted to follow up on this before I forget. Our current release cycle has implemented the "ideally..." comment I made last week. This will allow any upstream handler to add a .NET PrinterSettings object to the IPrintJob, which we will recognize and silently use inside our default Printer Dispatch Handler without any user intervention. That will allow you to plug in a handler, evaluate the document set being printed, set up your own PrinterSettings object (and optionally provide the user a Print Dialog), and then drop that object onto the print job which we will use when our Printer handler executes. This would probably be a more straightforward approach for you, rather than attempting the default printer sleight of hand suggestion I offered. I hope that helps.
roteague
Posts: 292
Joined: Thu Sep 25, 2008 4:49 pm
Location: Honolulu, Hawaii

Re: Printing Pipeline Targets

Post by roteague »

Mark McKenna wrote:I wanted to follow up on this before I forget. Our current release cycle has implemented the "ideally..." comment I made last week. This will allow any upstream handler to add a .NET PrinterSettings object to the IPrintJob, which we will recognize and silently use inside our default Printer Dispatch Handler without any user intervention. That will allow you to plug in a handler, evaluate the document set being printed, set up your own PrinterSettings object (and optionally provide the user a Print Dialog), and then drop that object onto the print job which we will use when our Printer handler executes. This would probably be a more straightforward approach for you, rather than attempting the default printer sleight of hand suggestion I offered. I hope that helps.

Thanks Mark, I'll pass that along. Everyone will be very happy.
Robert
roteague
Posts: 292
Joined: Thu Sep 25, 2008 4:49 pm
Location: Honolulu, Hawaii

Re: Printing Pipeline Targets

Post by roteague »

Mark McKenna wrote:I wanted to follow up on this before I forget. Our current release cycle has implemented the "ideally..." comment I made last week. This will allow any upstream handler to add a .NET PrinterSettings object to the IPrintJob, which we will recognize and silently use inside our default Printer Dispatch Handler without any user intervention. That will allow you to plug in a handler, evaluate the document set being printed, set up your own PrinterSettings object (and optionally provide the user a Print Dialog), and then drop that object onto the print job which we will use when our Printer handler executes. This would probably be a more straightforward approach for you, rather than attempting the default printer sleight of hand suggestion I offered. I hope that helps.
Mark, has this been implemented yet?

Thanks,

Robert
Robert
Mark McKenna

Re: Printing Pipeline Targets

Post by Mark McKenna »

Yes, it is implemented in our upcoming 2.4 release ("Dawson").

There is a new IPrintJob property key named "PrinterSettings", the value of which may be null (default) or an object of type System.Drawing.Printing.PrinterSettings. The printer print job handler will look there specifically for an object, and if one exists of the correct type, it will automatically and silently direct the printed output there. You will need a handler of your own to execute prior to our printer handler in order to "inject" the printer settings into the pipeline, if you will.
Mark McKenna

Re: Printing Pipeline Targets

Post by Mark McKenna »

Actually, Robert, my mistake. It looks like this had already been implemented in version 2.3 ("Morgan"), which we released some months back.
Post Reply