testing 0.9.8 for the cClose hangs problem, i saw it seems ok on my machine.
Now i have implemented and distributed my software that use the pdfcreator com interface and on same machines the problem still appear. When hangs, it uses 100% of the cpu resource. Taskmanager is then needed to terminate it.
Forums are in large part inaccesibles so i have made a new post to have infos about. May i hope in a solution? and when?
thank you.
Thanks for the reply.
Do you have any ticket for this issue so we can track it for changes?
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
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
Yes I have the same problem with 0.9.6. Love to get an answer/solution.
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