VPEDoc.PrintDoc() fails to return

[EthicsGradient]

Hi,

We're using the VPE 3.5 ActiveX control on Win XP and have a situation where, periodically, calls to PrintDoc() are failing to return.

The code used to print the document is as follows:

Code: Select all

VPEDOc.PrintOptions = PRINT_ALL + PRINT_NOABORTDLG

Log("VPE Print START")
VPEDoc.PrintDoc(0)          && hangs here
Log("VPE Print END")


What we end up with is an application that appears frozen, and a VPE Ctrl print job in the print queue that is endlessly spooling...

The catch is that this only occurs once every 20 jobs or so at 1 site, and we have a couple of thousand other sites executing the same code without a problem.

Any thoughts ?

cheers,
Matt.

[IDEAL Software Support]

Any thoughts ?

Not really. Maybe problems with the network, if the printer is connected via network.

[EthicsGradient]

I don't believe its network related - its a dedicated printer via USB. I can print other jobs from the same machine through the same print queue "around" the VPE job that is still spooling...and the VPE job is always small. one page with a couple of barcodes.

Is there any logging within the VPE ocx that I can turn on to see how far it gets before it stops ?

bottom line is PrintDoc() never returns, so our application hangs - though this is intermittent.

In the mean time, there is a VPE job sitting in the print queue in a state of "Spooling" that I can't cancel.

[IDEAL Software Support]

Due to the use in some large-scale projects, where VPE is installed on millions of machines, I rather assume the driver or the machine has a bug, since you are the only one reporting such a problem. And even you report that this happens only on a single machine, whilst you are running VPE on thousands of machines.

We could create a special debug version, but doing so and analyzing the log file is very time consuming. Under the current circumstances we see no requirement to do so - except you want us to do so in the context of our premium support.

[EthicsGradient]

Due to the use in some large-scale projects, where VPE is installed on millions of machines, I rather assume the driver or the machine has a bug, since you are the only one reporting such a problem. And even you report that this happens only on a single machine, whilst you are running VPE on thousands of machines.

We could create a special debug version, but doing so and analyzing the log file is very time consuming. Under the current circumstances we see no requirement to do so - except you want us to do so in the context of our premium support.

Not quite sure where the angst is coming from here.

Our product, which has been using VPE for many years now, generating the same basic document many times a day at 1000s of sites - is suddenly stopping approx. 1 in every 30 times on the call to VPE.PrintDoc() on all machines at a particular site. All machines have dedicated printers connected via USB.

I, also, would assume that the driver or the machines have a bug - given that we are ALSO running our software at thousands of sites in similar configurations, same printers, and same drivers, without a problem - but I have not yet been able to locate the problem - or resolve the issue for our client.

The question for me, then, is why PrintDoc() doesn't return to the calling application - even if it fails to spool the job. If I can resolve that question, perhaps I can then get to the root cause. Why WOULDN"T I raise that question here ?

[IDEAL Software Support]

We do not know where it hangs. It is very likely that it hangs when calling a function of a driver or the Windows printing system.

As already offered, we can analyze the problem for you in the context of our premium support. If you wish to do so, please contact our tech support by e-mail.

But I overlooked that you are using VPE v3.50, which was released in the year 2002. For this old version we do not offer analysis services nor would we patch it. I suggest you update to the current version 6.0 of VPE first.

[EthicsGradient]

For anyone interested... what the root cause is, I don't know, but the resolution was to disable the Auto-Sleep mode feature on the printers in question.

There is soemthing more to it as, even in sleep mode, on most occasions the print job was processed successfully.

By turning off auto-sleep mode, we went from a 90% success rate to 100% success rate.

[EthicsGradient]

FWIW, this was also occurring with VPE4.0 which we also have.