This project is read-only.

Running from within a COM server : error # 125 ('Printer is not ready') at line 7738 of


Hi all,

Trying to print reports as PDF using FoxyPreviewer:

do fails at server startup:

_REPORTOUTPUT = '' && in _Libs\FoxyPreviewer\ in production
do && in production mode, error # 125 ('Printer is not ready') at line 7738 of

full server startup source code is here:

here are the default printer security settings:

Important note: 2 COM servers instances are running, it may have an influence on the outcome: tutotest/ bin/ wc.dll?_maintain~ShowStatus (URL obfuscated to avoid SE indexing)

Any advice ?

thierry nivelet (foxincloud)


VfpImaging wrote May 3, 2016 at 6:31 PM

Salut Thierry,

Unfortunately, I have no experience in running FoxyPreviewer with COM servers.
AFAIK, the REPORT FORM command is not supported in COM servers????

FoxInCloud wrote May 4, 2016 at 9:12 AM

Oi Cesar,

REPORT FORM command is not supported in COM+ (dll) VFP automation servers, and supported in COM (exe) VFP automation servers, and this is what FoxInCloud (and Web Connect) use.

Strangely this error sometimes does not occur - I remember once being able to run a report with FoxyPreviewer in COM mode during my tests.

Do you know any printer setting that we could tamper around?

FoxInCloud wrote Oct 12, 2016 at 11:26 AM

Did some more research, line 7738 seems to be in FoxyInitForm.Init():
m.loHelper = CREATEOBJECT("PreviewHelper", .T.)
I think it fails on:
cPrinterName = SET("Printer",3)
I've checked on the server: opened a VFP IDE and executed SET("Printer",3) in the command window: observed a slight delay first time, no delay on subsequent calls.

After this I restarted the exe COM server: OK, no error

Maybe a COM server does not accept waiting until printer is ready.

Testing this workaround:
Sys(13) && 2016-10-12 thn -- {FiC V 2.22.0-beta.8} {en} added as workaround to error # 125 ('Printer is not ready') at line 7738 of -

Will report whether it works

FoxInCloud wrote Oct 12, 2016 at 11:30 AM

FoxInCloud wrote Oct 21, 2016 at 10:22 AM

Sys(13) does not seem to fix the issue consistently;
sometimes work, sometimes does not.

opening a session on the server and viewing the printer's property seems to be a valid, though unpractical, workaround.