This seems like an odd issue to me but I'm hoping I'm just missing something simple. But this should of course still be correct.
It seems not logical to use the FPU for integer (non-floating point) calculations, certainly not for small numbers. At least -0 + 4 was reported to produce 3 (at 4 positions). Issue with vDos native print processor the printout is very light when printing in condense modeīy change, I got yesterday something similar reported: Using the vDos FPU to do integer calculations, the result is sometimes 1 off: 2+2 (9 significant positions) -> 4 2+2 (8 ,) -> 3 !!! Maybe your program is doing something simular: menu item number + menu page offset = 22+0 -> 21. Is there any setting to sort out this problem? Jos its printing perfectly but issue is I have to comeout of the program & vDosplus and then only printing starts.
If i run on the client machine independently (with reference to the mapped drive) it works. No its recognising the drive the program opens and in clipper it returns me an error while program is open on some other pc.
You cannot set the printer driver to waste more inkt in non-economy mode or whatever? Jos If it is printing to a printer (LPT1 port or something else), using the DOS ASCII operation mode of the printer: Add the RAW option to the printer driver selection in config.txt (see Printing.pdf). What version of vDos are you using, and did you have a look at an eventual CLIPPER= that was before? Josĭon’t get what you’re actually asking. JosĭOS2USB HAS ASKED me TO USE "CMD /C type #LPT1.ASC > PRN". If you tested this out at the vDos/DOS command prompt: Create a (Window) batch file (d2uprint.bat) in the vDos directory with: type #LPT1.ASC > PRN Then in config.txt: lpt1="d2uprint.bat" Eventually append HIDE to dismiss of the Windows command line window.