Flushing device output buffers without closing handles

[JeremyR]

Hello,
I am writing data to a dot matrix printer on lpt1 using open for output / close statements. I have found that the data is not actually sent to the printer until either the port is closed or some buffer behind the scenes fills up.

I realize I can simply close the port and reopen it whenever I want to flush the contents of whatever buffer is holding my data, but is there a more elegant way to flush the data? I found some DOS interrupts that look like they are supposed to work, but apparently (from minimal messing around with them) they only work for files and not physical ports. Thanks for your help.

Jeremy Rosenberg
blandestvertigo@yahoo.com

[Ralph]

Because the instructions might be overwhelming, I decided to send Jeremy an email, with the 7-byte long program, FF.COM, which sends a form-feed character hex 0C to the port LPT1: which is where a printer is usually connected to. Works fine for me!

[JeremyR]

Thank you very much Ralph for responding so soon and by email as well. (and even more so for compiling the program for me!).

I am aware that a FF should cause the printer itself to print if it has data buffered. However, I believe that this is something on the host computer's side, not the printer's. I also believe that this is due to using OPEN, PRINT, and CLOSE statements rather than the LPRINT statement.

If you are interested, please try a similar test, but opening the port with:

'''''''''''''
DIM OutputDevice AS INTEGER

OutputDevice = FREEFILE
OPEN "lpt1" FOR OUTPUT AS OutputDevice
PRINT #OutputDevice, "Hey Ralph how are you?";
PRINT #OutputDevice, CHR$(12);
PRINT "Press any key to close the port I/O. Notice that the printer does not print until you do so."
PRINT "Ideally, I could call some sort of Flush routine or interrupt here so the printer would start printing without me having to wait until the CLOSE statement below."
DO
LOOP UNTIL INKEY$ <> ""
CLOSE OutputDevice
'''''''''''''

I hope that example is good enough to portray my problem here.
I must use OPEN, PRINT, and CLOSE statements rather than the LPRINT statement so the user can enter a device _or_ a file for the output, not just one or the other. This ensures they could type something like "C:\test.txt" or something like "lpt1" without me having to do hard coded checks like "IF OutputDevice = "lpt1" THEN UseLPRINT = 1" and the like and stick a bunch of checks throughout my (already lengthy) module.

In my configuration, I am running QB4.5 in a simulated command prompt in Windows XP Pro (that may have something to do with it as well). I will try from true DOS tomorrow when I get back to work.

Anyways, again, I sincerely thank you for your help and look forward to hearing from you again if you are still interested in solving this with me. There must be a way. I will post the results of my true DOS check tomorrow.

Thank you!

Jeremy Rosenberg
Oki Data Americas, Inc.
Software Developer
Software / Hardware QA Tester
blandestvertigo@yahoo.com

[JeremyR]

Hello,

I have confirmed that this is a problem with running it in a simulated prompt under Windows XP. The printer prints beautifully in vanilla DOS without me having to close the port first. However, it really would be convenient (although not absolutely essential) to be able to perform this way inside Windows XP as well. There has to be a way, but for now, this is good enough.

Thanks a lot once again for your help.

Jeremy Rosenberg
Oki Data Americas, Inc.
Software Developer
Software / Hardware QA Tester
blandestvertigo@yahoo.com

[Ralph]

I'm not sure of what your problem is, Jeremy.

I started QuickBASIC in Windows XP Home Edition, ran your program, and it printed when the CLOSE statement was executed, just as you said.

I put a BREAKPOINT just before the DO...LOOP, and ran the program. When it reached the BREAKPOINT and stopped, I clicked on Windows Explorer, found FF.EXE, double clicked it, and, the printer printed, without having to CLOSE the buffer #outputdevice.

At present, I really don't understand your true problem. Maybe if you could post an example of what you mean...?

Edited later:
As an afterthought, I ran a "DOS Prompt", opened QB from within it, entered your program, and ran it similarly to above. The printer behaved the same as before, both for the FF.EXE and for closing the buffer.

[JeremyR]

Hi Ralph,

The problem is that many of my test cases must not be form fed as they are testing paper movement. Therefore it is unacceptable (in some cases) to send FF to make the printer begin.

I figured out that it does not actually wait for CLOSE. It is a delay for about 1 minute until it thinks the connection may have been lost and flushes its buffer.

In any case, you're saying that it worked the same in vanilla dos, but for me, it printed immediately after receiving data with no buffering. It could be DOS version specific or more likely printer specific. Some printers, especially non-SIDM always wait for a form feed command because since the paper always needs to be ejected anyway, it doesn't make any sense to print anything until it has all of the information for an entire page. This is not the case for dot matrix. If you were using an SIDM, then I have no idea why we get different results in DOS.

I've pretty much given up. Since the delay only occurs (at least for me) while inside windows and it is only about a minute, it shouldn't be a problem.

Thanks for your time.

Jeremy Rosenberg
Oki Data Americas, Inc.
Software Developer
Software / Hardware QA Tester
blandestvertigo@yahoo.com

[John_Schofield]

Hi

Have you tried checking your printer settings?

I had a similar problem and found that by changing the settings a little this sorted it. The setting I changed was in the spool settings on the "details" tab to make sure that "spool msdos print jobs" was not selected.

The other thing to try (possibly one at a time) is in "spool settings" to select "print directly to printer" rather than spooling, but my printer seems to be ok with this unset as long as the msdos print jobs spool isn't set.