Skip to main content

[archive] Pause after close print file

  • April 20, 2009
  • 9 replies
  • 0 views
D

[Migrated content. Thread originally posted on 19 April 2009]

We use the CutePDF writer.

When a print file is closed the pdf file name created depends on registry entries that specify either
A) ask the user to specify the location of the print file with a save-as dialogue box
or
B) where to place the print file with a filename programatically set with registry values.

We have recently noticed that after a print file is closed, there seems to be a varying delay before the cutepdf driver seems to know that the print file has been closed.

For instance, we would set the output filename to c:\\temp\\output.pdf and to inhibit the save-as dialogue box, write the report, close the print file and then reset the registry entries to activate the save-as dialogue box true and have no file name specified (ready for the next report). Sometimes it seems that the pdf driver does not read the registry before it has been reset by our program AFTER the print file was closed, (i.e. it loses the bypass filename) and it then displays the save-as dialogue box.

I have found that using c$sleep for 3-5 seconds stops the problem and allows enough time between the close of the print file and the re-setting of the registry entries to allow the pdf driver to store the report where required. But this is not really a good solution.

Is there any way to ensure that the print file CLOSE statement affects the pdf driver more quickly or is there a way to wait for that event to have occurred?

We run version 7.2 under Windows XP most of the time.

    9 replies

    D

    [Migrated content. Thread originally posted on 19 April 2009]

    We use the CutePDF writer.

    When a print file is closed the pdf file name created depends on registry entries that specify either
    A) ask the user to specify the location of the print file with a save-as dialogue box
    or
    B) where to place the print file with a filename programatically set with registry values.

    We have recently noticed that after a print file is closed, there seems to be a varying delay before the cutepdf driver seems to know that the print file has been closed.

    For instance, we would set the output filename to c:\\temp\\output.pdf and to inhibit the save-as dialogue box, write the report, close the print file and then reset the registry entries to activate the save-as dialogue box true and have no file name specified (ready for the next report). Sometimes it seems that the pdf driver does not read the registry before it has been reset by our program AFTER the print file was closed, (i.e. it loses the bypass filename) and it then displays the save-as dialogue box.

    I have found that using c$sleep for 3-5 seconds stops the problem and allows enough time between the close of the print file and the re-setting of the registry entries to allow the pdf driver to store the report where required. But this is not really a good solution.

    Is there any way to ensure that the print file CLOSE statement affects the pdf driver more quickly or is there a way to wait for that event to have occurred?

    We run version 7.2 under Windows XP most of the time.
    If you application run in a tight loop without IO, e.g. no DISPLAY/ACCEPT, the runtime will, due to efficiency not process IO messages from Windows. This could be causing what you see. Try to display something and add an ACCEPT (for instance ACCEPT FROM TIME) to see if this makes a difference.
    D

    [Migrated content. Thread originally posted on 19 April 2009]

    We use the CutePDF writer.

    When a print file is closed the pdf file name created depends on registry entries that specify either
    A) ask the user to specify the location of the print file with a save-as dialogue box
    or
    B) where to place the print file with a filename programatically set with registry values.

    We have recently noticed that after a print file is closed, there seems to be a varying delay before the cutepdf driver seems to know that the print file has been closed.

    For instance, we would set the output filename to c:\\temp\\output.pdf and to inhibit the save-as dialogue box, write the report, close the print file and then reset the registry entries to activate the save-as dialogue box true and have no file name specified (ready for the next report). Sometimes it seems that the pdf driver does not read the registry before it has been reset by our program AFTER the print file was closed, (i.e. it loses the bypass filename) and it then displays the save-as dialogue box.

    I have found that using c$sleep for 3-5 seconds stops the problem and allows enough time between the close of the print file and the re-setting of the registry entries to allow the pdf driver to store the report where required. But this is not really a good solution.

    Is there any way to ensure that the print file CLOSE statement affects the pdf driver more quickly or is there a way to wait for that event to have occurred?

    We run version 7.2 under Windows XP most of the time.
    We use the CutePDF as well and have used a C$SLEEP to resolve this issue. I think it's because the ghostscript is converting the file after the printer is closed. I don't know of a way to know for sure when it's done, but the C$SLEEP has worked for us for years.
    D

    [Migrated content. Thread originally posted on 19 April 2009]

    We use the CutePDF writer.

    When a print file is closed the pdf file name created depends on registry entries that specify either
    A) ask the user to specify the location of the print file with a save-as dialogue box
    or
    B) where to place the print file with a filename programatically set with registry values.

    We have recently noticed that after a print file is closed, there seems to be a varying delay before the cutepdf driver seems to know that the print file has been closed.

    For instance, we would set the output filename to c:\\temp\\output.pdf and to inhibit the save-as dialogue box, write the report, close the print file and then reset the registry entries to activate the save-as dialogue box true and have no file name specified (ready for the next report). Sometimes it seems that the pdf driver does not read the registry before it has been reset by our program AFTER the print file was closed, (i.e. it loses the bypass filename) and it then displays the save-as dialogue box.

    I have found that using c$sleep for 3-5 seconds stops the problem and allows enough time between the close of the print file and the re-setting of the registry entries to allow the pdf driver to store the report where required. But this is not really a good solution.

    Is there any way to ensure that the print file CLOSE statement affects the pdf driver more quickly or is there a way to wait for that event to have occurred?

    We run version 7.2 under Windows XP most of the time.
    We use the CutePDF as well and have used a C$SLEEP to resolve this issue. I think it's because the ghostscript is converting the file after the printer is closed. I don't know of a way to know for sure when it's done, but the C$SLEEP has worked for us for years.
    D

    [Migrated content. Thread originally posted on 19 April 2009]

    We use the CutePDF writer.

    When a print file is closed the pdf file name created depends on registry entries that specify either
    A) ask the user to specify the location of the print file with a save-as dialogue box
    or
    B) where to place the print file with a filename programatically set with registry values.

    We have recently noticed that after a print file is closed, there seems to be a varying delay before the cutepdf driver seems to know that the print file has been closed.

    For instance, we would set the output filename to c:\\temp\\output.pdf and to inhibit the save-as dialogue box, write the report, close the print file and then reset the registry entries to activate the save-as dialogue box true and have no file name specified (ready for the next report). Sometimes it seems that the pdf driver does not read the registry before it has been reset by our program AFTER the print file was closed, (i.e. it loses the bypass filename) and it then displays the save-as dialogue box.

    I have found that using c$sleep for 3-5 seconds stops the problem and allows enough time between the close of the print file and the re-setting of the registry entries to allow the pdf driver to store the report where required. But this is not really a good solution.

    Is there any way to ensure that the print file CLOSE statement affects the pdf driver more quickly or is there a way to wait for that event to have occurred?

    We run version 7.2 under Windows XP most of the time.
    Like minds!!

    It would seem a shame as it seems to be a good sultion to pdf creation. Clearly Cutepdf is not multi-threaded, as if it was the problem would go away. Also as it works now, two instances of our application trying to print to the Cutepdf printer always gets in a mess.

    Maybe I'll take it up with them.
    D

    [Migrated content. Thread originally posted on 19 April 2009]

    We use the CutePDF writer.

    When a print file is closed the pdf file name created depends on registry entries that specify either
    A) ask the user to specify the location of the print file with a save-as dialogue box
    or
    B) where to place the print file with a filename programatically set with registry values.

    We have recently noticed that after a print file is closed, there seems to be a varying delay before the cutepdf driver seems to know that the print file has been closed.

    For instance, we would set the output filename to c:\\temp\\output.pdf and to inhibit the save-as dialogue box, write the report, close the print file and then reset the registry entries to activate the save-as dialogue box true and have no file name specified (ready for the next report). Sometimes it seems that the pdf driver does not read the registry before it has been reset by our program AFTER the print file was closed, (i.e. it loses the bypass filename) and it then displays the save-as dialogue box.

    I have found that using c$sleep for 3-5 seconds stops the problem and allows enough time between the close of the print file and the re-setting of the registry entries to allow the pdf driver to store the report where required. But this is not really a good solution.

    Is there any way to ensure that the print file CLOSE statement affects the pdf driver more quickly or is there a way to wait for that event to have occurred?

    We run version 7.2 under Windows XP most of the time.
    I have found that by setting the Cutepdf printer advanced properties to 'print directly to printer' solves the problem of ensuring that the close statement for the printer does insist that the pdf driver goes through its 'save the file somewhere' procedures correctly before releasing control back to the cobol program. This saves using the sleep command for a possibly over-compensating amount of time

    I have asked Acro software about the need for a multi threading version - will wait to see what they come back with.
    D

    [Migrated content. Thread originally posted on 19 April 2009]

    We use the CutePDF writer.

    When a print file is closed the pdf file name created depends on registry entries that specify either
    A) ask the user to specify the location of the print file with a save-as dialogue box
    or
    B) where to place the print file with a filename programatically set with registry values.

    We have recently noticed that after a print file is closed, there seems to be a varying delay before the cutepdf driver seems to know that the print file has been closed.

    For instance, we would set the output filename to c:\\temp\\output.pdf and to inhibit the save-as dialogue box, write the report, close the print file and then reset the registry entries to activate the save-as dialogue box true and have no file name specified (ready for the next report). Sometimes it seems that the pdf driver does not read the registry before it has been reset by our program AFTER the print file was closed, (i.e. it loses the bypass filename) and it then displays the save-as dialogue box.

    I have found that using c$sleep for 3-5 seconds stops the problem and allows enough time between the close of the print file and the re-setting of the registry entries to allow the pdf driver to store the report where required. But this is not really a good solution.

    Is there any way to ensure that the print file CLOSE statement affects the pdf driver more quickly or is there a way to wait for that event to have occurred?

    We run version 7.2 under Windows XP most of the time.
    Hi,

    We started using Cute PDF a while ago.
    I confirm, that Print Direct To Printer does seem to get rid of the file closure issue.
    From memory Acro software suggested to do this.

    Also during the time of starting to use Cute PDF, we encountered problems with WIN$PRINTER or something in the runtime.

    We were getting MAV's in V8.0
    Plus if the Microsoft document imaging printer was being used it really wrecked things for us.

    I did post on here somewhere regarding this and Gisle very promptly sorted the matter.

    Shaun
    D

    [Migrated content. Thread originally posted on 19 April 2009]

    We use the CutePDF writer.

    When a print file is closed the pdf file name created depends on registry entries that specify either
    A) ask the user to specify the location of the print file with a save-as dialogue box
    or
    B) where to place the print file with a filename programatically set with registry values.

    We have recently noticed that after a print file is closed, there seems to be a varying delay before the cutepdf driver seems to know that the print file has been closed.

    For instance, we would set the output filename to c:\\temp\\output.pdf and to inhibit the save-as dialogue box, write the report, close the print file and then reset the registry entries to activate the save-as dialogue box true and have no file name specified (ready for the next report). Sometimes it seems that the pdf driver does not read the registry before it has been reset by our program AFTER the print file was closed, (i.e. it loses the bypass filename) and it then displays the save-as dialogue box.

    I have found that using c$sleep for 3-5 seconds stops the problem and allows enough time between the close of the print file and the re-setting of the registry entries to allow the pdf driver to store the report where required. But this is not really a good solution.

    Is there any way to ensure that the print file CLOSE statement affects the pdf driver more quickly or is there a way to wait for that event to have occurred?

    We run version 7.2 under Windows XP most of the time.
    Hi,

    We started using Cute PDF a while ago.
    I confirm, that Print Direct To Printer does seem to get rid of the file closure issue.
    From memory Acro software suggested to do this.

    Also during the time of starting to use Cute PDF, we encountered problems with WIN$PRINTER or something in the runtime.

    We were getting MAV's in V8.0
    Plus if the Microsoft document imaging printer was being used it really wrecked things for us.

    I did post on here somewhere regarding this and Gisle very promptly sorted the matter.

    Shaun
    D

    [Migrated content. Thread originally posted on 19 April 2009]

    We use the CutePDF writer.

    When a print file is closed the pdf file name created depends on registry entries that specify either
    A) ask the user to specify the location of the print file with a save-as dialogue box
    or
    B) where to place the print file with a filename programatically set with registry values.

    We have recently noticed that after a print file is closed, there seems to be a varying delay before the cutepdf driver seems to know that the print file has been closed.

    For instance, we would set the output filename to c:\\temp\\output.pdf and to inhibit the save-as dialogue box, write the report, close the print file and then reset the registry entries to activate the save-as dialogue box true and have no file name specified (ready for the next report). Sometimes it seems that the pdf driver does not read the registry before it has been reset by our program AFTER the print file was closed, (i.e. it loses the bypass filename) and it then displays the save-as dialogue box.

    I have found that using c$sleep for 3-5 seconds stops the problem and allows enough time between the close of the print file and the re-setting of the registry entries to allow the pdf driver to store the report where required. But this is not really a good solution.

    Is there any way to ensure that the print file CLOSE statement affects the pdf driver more quickly or is there a way to wait for that event to have occurred?

    We run version 7.2 under Windows XP most of the time.
    You have a better memory than me Shaun :-)
    D

    [Migrated content. Thread originally posted on 19 April 2009]

    We use the CutePDF writer.

    When a print file is closed the pdf file name created depends on registry entries that specify either
    A) ask the user to specify the location of the print file with a save-as dialogue box
    or
    B) where to place the print file with a filename programatically set with registry values.

    We have recently noticed that after a print file is closed, there seems to be a varying delay before the cutepdf driver seems to know that the print file has been closed.

    For instance, we would set the output filename to c:\\temp\\output.pdf and to inhibit the save-as dialogue box, write the report, close the print file and then reset the registry entries to activate the save-as dialogue box true and have no file name specified (ready for the next report). Sometimes it seems that the pdf driver does not read the registry before it has been reset by our program AFTER the print file was closed, (i.e. it loses the bypass filename) and it then displays the save-as dialogue box.

    I have found that using c$sleep for 3-5 seconds stops the problem and allows enough time between the close of the print file and the re-setting of the registry entries to allow the pdf driver to store the report where required. But this is not really a good solution.

    Is there any way to ensure that the print file CLOSE statement affects the pdf driver more quickly or is there a way to wait for that event to have occurred?

    We run version 7.2 under Windows XP most of the time.
    I do remember the print direct option now. There was a reason that we couldn't use that, but I don't remember. Glad you got it working. Fortunately, I haven't seen any issues with it in v8.x yet. If I do, I'll be sure to check out Gisle's solution.
    1 Attachments

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement