|
Post by davidc on Jul 21, 2018 16:01:16 GMT 1
Have been printing pdf documents from dBase without issue and without ever any config code interventions by me.
Now the printing process doesn't reach the "Save print output as" (waiting for file name and destination).
What it does do is send #LPT1.asc and a #LPT1.txt files to the vDos folder. Then dBase goes into "not responding" forever.
There were a couple of Windows 10 updates installed within the subject period, since uninstalled without benefit.
Probably more importantly, I was inexpertly 'mucking-around' trying to move the 'downloads' folder onto my desktop and in the course of that threw up some odd results that I thought I'd worked out/around. Of course now I'm some fruitless hours down the track and starting to feel a cold sweat.
Aside from dBase printing jobs all other printing directed to pdf output work fine and in the same way as dBase output.
Most grateful for any tips.
|
|
|
Post by davidc on Jul 21, 2018 16:13:45 GMT 1
Not dissimilar result sending to a physical printer. Skips "Save print output as" screen and produces the two #LTP1 files in the vDOS folder and the printer reports "error".
|
|
|
Post by davidc on Jul 21, 2018 16:24:08 GMT 1
Maybe should add that the txt output is fine - just won't go to pdf file
|
|
|
Post by Jos on Jul 21, 2018 17:54:22 GMT 1
I assume you printed to PDF in the past by a virtual PDF printer.
By what you describe, I suspect you have a LPT1 = … RAW … line in config.txt. That RAW option tells vDos to instruct the printer driver to pass the ASCII data unmodified to the actual printer. A virtual PDF printer doesn’t manage an actual printer and will often just stall and keep vDos waiting for completion. If the printer driver manages a Windows-only (GDI) printer, sending ASCII data to that won’t be understood and cause the printer to enter an error condition.
Jos
|
|
dc
Guest
|
Post by dc on Jul 22, 2018 3:16:51 GMT 1
Jos, thanks for getting in touch.
Yes, until yesterday printing to PDF in the past has been problem free.
No, I have never edited the config.txt file.
Looked like the old config file I'd been using came with only:
WINDOW=30
FRAME=ON
And the new one (upgraded vDos yesterday) has no operative lines.
I set-up a usb drive with all by dBase stuff in one folder and vDos file in another folder, then used another Windows 10 machine (that I hadn't been fiddling with).
The result of trying to print to PDF gave the same result - the two #LPT1 files in the vDos folder.
Does this seem to confirm your idea that vDos has somehow got itself configured in LPT1=RAW like state?
It seems so strange that things should go awry with apparently nothing done to provoke it.
Additionally, on the second computer with all files on the usb drive, when the print job was sent to a physical printer, the #LPT1 files still appeared in the vDos folder . . . however the 3 lines of print output did make it through to the Brother printer but the printer got stuck in limbo and didn't spit-out the printed page until it was turned off.
David.
Sorry about being slow to reply - I'm in Australia (more specifically, Tasmania).
|
|
|
Post by Jos on Jul 22, 2018 9:20:49 GMT 1
vDos never came with “WINDOW=30” and “FRAME=ON” lines in config.txt, so someone will have changed that file…
Before any printing is started, vDos will create an .asc and .txt file. Those are of no use to vDos itself, but to accommodate an eventual external print processor program (.asc), or to import the print data into a Windows program (.txt).
The problems you described indicate the RAW option is used, the virtual PDF and a GDI printer driver will choke on that. The RAW option has to be set by hand in the config.txt file since the default is the internal print processor parsing the print data.
Download vDosSetup off the vDos site again, install vDos to, and start it from a separate folder. After ending the DP demo program, do a COPY AUTOEXEC.TXT LPT1 at the command prompt to confirm printing works correctly and start from there…
Jos
|
|
|
Post by davidc on Jul 22, 2018 10:15:03 GMT 1
Thanks Jos, will do.
Just thinking out loud . . . yesterday I did isolate (renamed) the then current vDos version and did the latest download and installation.
From its new vDos folder with a config file with nothing but rems in it (if I'm not mistaken) - there was no change to the defective print process.
That seems to suggest nothing amiss with vDos itself, the new one being uncompromised.
As mentioned - tried via usb stick on alternative Windows 10 machine - still no good - suggesting problem wasn't to do with a setting/defect on my original machine.
That could lead us to the simplistic conclusion that I got a problem (corrupt file - not unheard of) in dBase.
I will also chase up an alternative set of dBase files.
Cheers DC
|
|
|
Post by Jos on Jul 22, 2018 10:37:56 GMT 1
vDos stalled when printing to a virtual PDF printer; at that moment it is just waiting for the printer driver to complete. No attention is given that moment at the DOS program. Corrupt dBase files will affect dBase operation, not vDos. You also stated the #LPT1 files looked fine. If you start vDos.exe (double click) in the new installation folder, and the DP demo program starts, you know for certain those autoexec.txt and config.txt files are used. Not those for instance defined by the Start in directory of a shortcut. You did at least change the autoexec.txt or its location to start your program…
Jos
|
|
|
Post by davidc on Jul 22, 2018 12:06:33 GMT 1
Oh dear - just lost my reply - here goes again.
I will do the new download etc that you mentioned in a moment.
I the meantime I have started the latest version of VDos from its folder and found, unlike yesterday when it executed my 'start.prg' from the autoexec line 'DBASE START', today it just lists the autoexec lines and down to my 'DBASE START' line and leaves the '-' cursor on the next line. (I'll list below).
On the other hand, if I rename the vDos folders (new and earlier vDos versionS) and start the older ver vDos, it executes my 'start.prg' and all works fine until printing required.
Now, I haven't mentioned before that the #LPT1 files that appear in the vDos folder appears 1 second after the "Print Setup" window appears - and in its present settings has a Canon printer nominated. If I the cancel "Print Setup" (the #LPT1 file having been created) the my Dbase apps work fine (but not printing of course).
rem This is essentially the DOS autoexec.bat. rem =========================================
rem At startup, C: is the only drive letter known by vDos. rem But this vDos C: is NOT Windows C: !!!
rem vDos drive letters don't have to match those of Windows. rem It's even adviced they don't, to limit access to the Windows file system.
rem The USE command assigns vDos drive letters to Windows drives, folders, rem or network shares. The command syntax is: rem USE <vDos drive letter:> <Windows drive:|folder|network share>\ rem Examples: USE C: D:\dosprog\, USE F: \\server\share\dosprog\.
rem By default C: is assigned to the folder vDos.exe is started from. rem Call the batch file that launches the DataPerfect demo program: rem CALL DPTEST\STARTDP (remmed by me)
USE C: C:\PORK\
USE E: E:\
DBASE START
|
|
|
Post by davidc on Jul 22, 2018 12:28:57 GMT 1
Ok, have complied with you earlier instruction and after new install etc copied COPY AUTOEXEC.TXT LPT1 at the command prompt to confirm printing works.
The "Print Setup" window appeared as expected but the contents of autoexec.txt appeared in one of the now customary two #LPT1 files in the vDos folder and vDos went into the 'not responding' state.
I hope that narrows things down . . .
Cheers DC
|
|
|
Post by davidc on Jul 22, 2018 12:56:13 GMT 1
An additional point - if after COPY AUTOEXEC.TXT LPT1 is entered at the command prompt and the #LPT1.txt is generated in vDos folder, I then cancel the "Print Setup" a new C:\> prompt appears and I can COPY AUTOEXEC.TXT LPT1 again and again as long as I cancel the "Print Setup".
DC
|
|
|
Post by davidc on Jul 22, 2018 12:59:12 GMT 1
All this is after weeks/months of trouble free operation/printing etc!!! DC
|
|
|
Post by davidc on Jul 22, 2018 13:39:51 GMT 1
Just reflecting on the detail of your earlier comment: "vDos stalled when printing to a virtual PDF printer; at that moment it is just waiting for the printer driver to complete."
In terms of the timing of events we have the two #LPT1 files being created 1 second after the appearance of the "Print Setup" window (and the same for the earlier vDos ver 2017-08-01) and that is regardless of which is current 'default' or specified printer (PDF or physical). And I don't think vDos can be said to have stalled at this point, it stalls 4 seconds after the OK button of "Print Setup" is clicked.
If I go on to press another key, say esc, the vDos window greys-out and the little revolving 'thinking/waiting' wheel continues to turn.
DC
|
|
|
Post by Jos on Jul 22, 2018 14:06:37 GMT 1
You could have a look at the creation time of both files, that will be before the Print Setup dialog popups. The file manager (Windows Explorer?) will postpone displaying file changes.
When vDos determines a DOS printjob has finished (mostly by timing out), it will first create those two files. Only if they are actually created (else an error message will be displayed and printing cancelled), proceed with whatever is defined in config.txt, defaulting to the internal print processor w/o options.
Since you now have a clean vDos directory and the problem still occurs with the mere COPY AUTOEXEC.TXT LPT1, you can zip the lot and post it over here. I (and others) should then be able to reconstruct it… Mind, it appears you have to register to the forum before you can add an attachment.
Jos
|
|
|
Post by davidc on Jul 22, 2018 14:09:11 GMT 1
Now here's a curious development.
I went into the computer's settings/printers and scanners/miscrosoft print to pdf/manage/open print queue, which opened up the little 'microsoft to pdf' print queue window. Then went back and went thru the COPY AUTOEXEC.TXT LPT1 process. 'print to pfd' was selected in the 'print setup' window and OK clicked. The expected #LPT1 files were generated in the vDos folder. Nothing appeared in the little print queue window. However . . . . The SAVE PRINT OUTPUT AS window did unexpectedly appear and a file name was given and the file properly created. Clicked in another COPY AUTOEXEC.TXT LPT1 and printed another output file successfully (the two #LPT1 files being overwritten with new ones). Clicked in another COPY AUTOEXEC.TXT LPT1 and the SAVE OUTPUT window failed to appear and vDos stalled as usual.
Have had mixed success with repeats of this approach.
Am sure you will make something of all of this!
DC
|
|