As many before me I've got a real problem with knowing when the print is done.
I've created really nice application based on BullZip converting multiple documents from a document management software to pdf with merge and all..
Using runonce is fine for small files but when I'm merging or converting word documents of 50 pages, runonce is deleted but the job is still running, the printer is working and the document is far from being done.
In your documentation said that it possible to use AfterprintProgram , but it's also say that you have to give it a valid command line, my only problem is that I can't fine anyware what are the supported parameters for command line.
Please direct me to command line list , or give me a vba code example for hooking into printing process.
With appreciation
Bull head
Hooking into printing process
Moderator: jr
Re: Hooking into printing process
BH, is this what you need ?
From http://www.biopdf.com/guide/settings.php
afterPrintProgram The AfterPrintProgram setting is a hook into the printing process. If you specify this setting it must contain a valid command line that will be launched when the PDF document is created. The command line can include the %1 token that will be substituted with the full path of the created PDF file. %2 will be the number of pages created. %3 is the number of files created. The command specified here will run regardless of the result of the document creation. For conditional command lines you should use RunOnSuccess and RunOnError.
I'm also interested in using it, but have not tried. My docs are quite small (4-5 pages) and checking for runonce does the job.
Regards, Oscar.
From http://www.biopdf.com/guide/settings.php
afterPrintProgram The AfterPrintProgram setting is a hook into the printing process. If you specify this setting it must contain a valid command line that will be launched when the PDF document is created. The command line can include the %1 token that will be substituted with the full path of the created PDF file. %2 will be the number of pages created. %3 is the number of files created. The command specified here will run regardless of the result of the document creation. For conditional command lines you should use RunOnSuccess and RunOnError.
I'm also interested in using it, but have not tried. My docs are quite small (4-5 pages) and checking for runonce does the job.
Regards, Oscar.
Re: Hooking into printing process
Hi,
I've made some tests, and as said before; waiting for runonce is the best method I've found until now.
My approach was trying to open the recently created pdf file for exclusive read access and performance hit was huge. Testing with very small files average 8k in rtf file and 90k printed in pdf performed almost double the time using that approach; printed 4 files in 8 seconds with runonce 14 seconds watching for read access.
This approach has another problem, If the pdf file already exist. I managed it by deleting the pdf file prior printing, but also added some extra processing time.
Any way, it works as expected. You might say ... hey are just seconds ... and your right. I print 700 documents (fortunately once a month); rounding to 9 seconds using runonce, the job is done in about 26 minutes, using file access rounding to 15s the job is done in 44 minutes. Hey ... now we talk about minutes.
Not having multithreading capabilities, we are stuck to this numbers. Have not tried the AfterPrintProgram feature, don't want to bang my head thinking in a callback function to return control to main app; maybe because do not fully understand that feature.
If you want to give a try what I did, here is the code in C#:
while (true)
{
try
{
FileStream FilePrinted = File.Open(sTargetFile, FileMode.Open, FileAccess.Read,FileShare.None);// OpenWrite(sTargetFile);
//Console.Write(FilePrinted.Name + " ");
//Console.Write("*");
FilePrinted.Close();
break;
}
catch (System.IO.IOException)
{
// This is where we must be.
//Console.Write(".");
}
catch (Exception e)
{
Console.WriteLine("°");
}
}
I've made some tests, and as said before; waiting for runonce is the best method I've found until now.
My approach was trying to open the recently created pdf file for exclusive read access and performance hit was huge. Testing with very small files average 8k in rtf file and 90k printed in pdf performed almost double the time using that approach; printed 4 files in 8 seconds with runonce 14 seconds watching for read access.
This approach has another problem, If the pdf file already exist. I managed it by deleting the pdf file prior printing, but also added some extra processing time.
Any way, it works as expected. You might say ... hey are just seconds ... and your right. I print 700 documents (fortunately once a month); rounding to 9 seconds using runonce, the job is done in about 26 minutes, using file access rounding to 15s the job is done in 44 minutes. Hey ... now we talk about minutes.
Not having multithreading capabilities, we are stuck to this numbers. Have not tried the AfterPrintProgram feature, don't want to bang my head thinking in a callback function to return control to main app; maybe because do not fully understand that feature.
If you want to give a try what I did, here is the code in C#:
while (true)
{
try
{
FileStream FilePrinted = File.Open(sTargetFile, FileMode.Open, FileAccess.Read,FileShare.None);// OpenWrite(sTargetFile);
//Console.Write(FilePrinted.Name + " ");
//Console.Write("*");
FilePrinted.Close();
break;
}
catch (System.IO.IOException)
{
// This is where we must be.
//Console.Write(".");
}
catch (Exception e)
{
Console.WriteLine("°");
}
}