Msg: Re: vDos users: be aware: can't print again if prior print has locked the port

Don't know if this will suit Harry, but if the desired result is an actual printed page, with no need to retain or review a pdf, the fix is bypassing the pdf altogether and going direct to the printer -- using the procedure previously detailed. Once it's set up, that process is transparent, just print as usual.

If the printer is off, the documents will queue up, as usual in Windows. And each pdf file saved automatically to the vdos directory will overwrite the previous one. So no locked ports.

From: Carl Distefano
To: xywrite@xxxxxxxx
Sent: Tuesday, September 13, 2016 10:32 AM
Subject: Re: vDos users: be aware: can't print again if prior print has locked the port

Harry,

>> vDos users: Be aware that printing using a PDF it locks the port, so you
>> must close out the PDF reader before you can print again. (Did I
>> get that right, ...

Not quite. It's not the port that's locked, it's the file, #LPT1.pdf,
which vDos saves PDF output to every time, that's locked -- by your
PDF application, not by vDos.

Kari,

> Carl has a personal workaround but this should be fixed at the system level.

My "workaround" is standard operating procedure for any Windows user
when a file you want to use is locked. You unlock it by closing the
file or doing a "Save As" to a different filename. Locking files is
the default behavior for most Windows applications. I suppose one fix
would be to find (or make) a PDF application that doesn't lock the
files it opens. (But not locking files on a modern OS has a downside,
too.)

At the vDos-(lfn) level, the only fix I can think of would be to
generate a unique filename for each print-to-PDF operation. The
filename could be saved to the user's Windows temp file directory
(%TEMP% and/or %TMP% in the Windows environment). The downside there
is an accumulation of temp files, but regular housekeeping should take
care of that.

--
Carl Distefano
mailto:cld@xxxxxxxx