Printing Pipeline Targets
Moderator: Phil Barton
Printing Pipeline Targets
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,
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
Re: Printing Pipeline Targets
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.
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.
Re: Printing Pipeline Targets
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.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.
Robert
Re: Printing Pipeline Targets
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.
Re: Printing Pipeline Targets
Great suggestion Mark, I'll take a look at something like that.
Robert
Re: Printing Pipeline Targets
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.
Re: Printing Pipeline Targets
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
Re: Printing Pipeline Targets
Mark, has this been implemented yet?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,
Robert
Robert
Re: Printing Pipeline Targets
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.
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.
Re: Printing Pipeline Targets
Actually, Robert, my mistake. It looks like this had already been implemented in version 2.3 ("Morgan"), which we released some months back.