0.9.8 cClose bug

Yes I have the same problem with 0.9.6. Love to get an answer/solution.

We are facing the same issue. This problem seems to be well known over several versions of Pdf Creator. I haven't seen any confirmation from the pdfforge team about this problem, is it a bug or is it wrong usage of the COM-interface by the users? I have tried to follow the procedures found in the examples but every now and then the cClose call isn't responding which leads to pdf creator hanging.

One possible workaround is to timeout the call to cClose and if the timeout occurs the pdfcreator process will be terminated with a "taskkill" command. This is a very ugly workaround, and I am curious on the pdfforge team:s conclusion to this issue. Is this something that will be fixed in a near future or what is the state of this issue?

Regards
Johan

Hello,

yes, this is a known bug in PDFCreator. In 0.9.8 we have done some improvements, that should fix it for some situations, but it seems that it does not impact all situations. In general, it hepls to increase the waiting timers, but that is very ugly as well, I have to admit. The problem is very hard to track, as it does not always happen and if it happens, it cannot be tracked in the debugger, as it adds additional waiting times.

But of course we are working on this.

kind regards,
Philip

Thanks for the reply.

Do you have any ticket for this issue so we can track it for changes?

Regards
Johan

Hi,

is there any prospect about when this bug is going to be solved?

thank you

Alex

Hello all,

I have the same problem and it seems that removing .cDefaultPrinter call before using .cclose is a workaround.

Hope this helps...

P.S. : Using pdfcreator 0.9.8 with MS Access 2000

Hi jdevillele,

what exactly do you mean with "removing .cDefaultPrinter call" ?

Thanks!

Alfred

I had the same problem.

Although PDFCreator seems to crash when calling the cClose() method, I found that in my environment that the cCloseRunningSession() worked without a hitch....definitely worth a try guys. Good Luck.

Regards

Isaac.

This cClose problem bedeviled me for some time; but I have found a workaround that always works.

It was a frustrating problem because sometimes the cClose method:

  1: would work (it always seemed to work when I was slowly ‘stepping’ through my code)

  2: would not work (like when I ran my code, often processing 100+ files with cCombineAll)

Either way my PDF file would be created, and when finished the Monitor showed no jobs in the que. But apparently cCountOfPrintjobs was NOT immediately being reset to "0".  I had never thought of checking this, but that's apparently where the problem hid.

The solution was to wait a few seconds for the system to catch up. So after my print job ran, I inserted the following “wait and see” code. It will wait in 5 second increments (for up to 5 minutes) checking to see if the cCountOfPrintjobs is "0" yet. Once cCountOfPrintjobs is 0 (usually within 5-25 seconds) it WILL cClose.

The cClose problem has not been an issue since using this method.

t = 0

QlastPrintJob: If mypdfjob.cCountOfPrintjobs >= 1 Then

Application.Wait (Now + TimeValue("0:00:05"))

t = t + 1

          If t > 60 Then ' 60 * 5 sec = 300 sec = 5 mins

          GoTo JustGetOut ‘ gotta know when to throw in the towel

          End If

GoTo QlastPrintJob

End If

If mypdfjob.cProgramIsRunning = True Then

   mypdfjob.cClose

   Application.Wait (Now + TimeValue("0:00:05")) ‘ just to be safe

   Set mypdfjob = Nothing

End If

I hope this is helpful,

Asherpa

Frank has been chasing this error for many days now and it seems that he has found the problem. It seems as if it is an issue with concurrent access in VB 6. If an unload request is coming, VB will leave any kind of Timer procedure and never continue it, which are used to check if new files are available to convert and such things. On the other hand, we have to wait until the timer procedures are finished, because the main form would load again automatically, if the timer is accessed again.

So this is a bit tricky and we are trying to find a solution to it.

kind regards,

Philip

I dont know if this will help anyone but it could enable someone to at least operate their PDFCreator until a fix comes along.

I have two machines that I'm testing PDFCreator 0.9.8 on.

One is a vista home premium laptop running office 2003 and Access and doesn't exhibit the above problem. However the other is a desktop Dell running XP Pro with the same version of Access and does exhibit the problem as discussed above.

I have tried various delay tactics in the second do loop as that's where the problem lies for me. My fix although a bit rough and ready is to put a simple msgbox() inside that loop. This seems to distract the loop and once you cancel the msgbox() everything carries on OK without the need to kill PDFCreator with Task Manager..

Part of Access sub as follows:-

   
    'Wait until the print job has entered the print queue
    Do Until pdfjob.cCountOfPrintjobs = 1
        DoEvents
    Loop

    pdfjob.cPrinterStop = False

    'Wait until PDF creator is finished then release the objects
    Do Until pdfjob.cCountOfPrintjobs = 0

    ' Removed DoEvents here and inserted the following line.
    MsgBox ("PDF File ready") 'My way of waking it out of its sleep
    Loop
   
    pdfjob.cClose
   
    'Reset the (original) default printer and release PDF Creator
    Set Application.Printer = Application.Printers(lngLPrinterCurrent)
    Set pdfjob = Nothing
   
End Sub

Edited 27/11/09

I took a look at the source code of 0.9.8 and the cClose function in clsPDFCreator.cls.

I think the problem is in this part :

Do
  DoEvents
Loop Until ProgramIsStarted = True

it's an infinite loop, no ?

and I didn't find where in the source you set ProgramIsStarted to false.

Why don't you go back to the old closing system in 0.9.3 if you have closing problems since 0.9.5

Hello,

I am afraid, that it is not that easy. We think it is solved now though. In a few days, we will have our final tests and the setup package ready for the public.

kind regards,

Philip

Ok, I just try to help !

so let's wait for the new version.

regards