[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Re: vDos users: be aware: can't print again if prior print has locked the port
- Subject: Re: vDos users: be aware: can't print again if prior print has locked the port
- From: Harry Binswanger hb@xxxxxxxx
- Date: Tue, 13 Sep 2016 11:40:09 -0400
Yes, I downloaded Sumatra. But I actually think it's better to see what's
going to print. Saves paper when I've (inevitably) made a mistake.
I print from Xy about once a month, so delays matter only to my vanity.
Thanks, though.
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@xxxxxxxxcld@xxxxxxxx