How to capture PRN / LPT1 output

[Unscruffed]

We have a DOS program at our workshop that does inventory / customer database / statements / invoicing etc; that prints everything to PRN (LPT1).

Because the app is DOS, we have a lot of printing reliability issues, and the ugly "console" style printing.

I'm trying to intercept the print output so that I can modify the data, then print it through Windows.

Basically, what I'm trying to achieve is a background app that will do the following:

1: capture the LPT1 output to a TEXT FILE
OR
capture the LPT1 output to STDIN
OR
capture the LPT1 output via COMMAND$

2: make modifications to "pretty-up" the output a bit (a nice modern format with graphic letterhead, TT fonts, tables, etc

3: send the modified data to the printer

Steps 2 & 3 are no problem once I have the original output, but I can't figure out any way to do step 1.

Anyone have any ideas?

Any help appreciated.

***********************************************************
FAQ Answers:

1: What I already tried:
I've looked at many 3rd party apps including:
* DosPrn - that's what we're currently using
* PrintFil
* Print Distributor
* a whole bunch of other stuff including print drivers
that are "supposed" to print to ascii files. (Hmmm)
I can't find anything that really does what I need.
I've decided the most reliable method will be a custom app.

2: The DOS App:
The DOS app is "DK Autoshop".
This app is "industry specific" for the Australian
Automotive industry. The latest update is still DOS,
and as such, will still present the same problems.

3: Alternatives:
There is no Windows app that does everything the DOS
app does, and is so easy to use. Changing software is
not an option in this case.
***********************************************************


Be good. If you can't, don't get caught!

 

[BobRodes]

Is your printing capability selected from a menu in your app, or is there a way to run print routines from a command line? If the latter, can you provid an example of the command to print something?

 

[HughLerwill]

Unless the DOS app has the ability to print to a plain text file you will probably have the added complication that it will be printing using a custom/ built-in print driver(for a limited list of specific printers) so the print 'stream' will include escape characters and other such trash.

 

[BobRodes]

Yes, there is that, too. You can generally write routines to filter out NPC's, but it can certainly be tedious.

 

[Unscruffed]

Having got a hold of the software to play with at home, I have found that some screens let you print to a pre-defined file and some don't.

Here is a link that shows 2 of the print screens:

http://noise-emission.com/dka/

The output file from the first page (invoice.txt) is an exact replica of what gets printed. I can use this file no problem.

I still can't capture the second page to file though.

There are many screens that you can print from, but it seens that only some give an option to print to file.

From what I've read, PRN will always print to LPT1 in DOS. This also shows as the "default" setting in all the print screens. I have found that by using a Hex editor, I can change the default to DSK. This will only work however, if DSK is an original option.



Be good. If you can't, don't get caught!

 

[Unscruffed]

Sorry Rob & Hugh, that didn't really answer your questions. Thanks for your fast replies.

I've had some time to experiment, and maybe, just maybe, I won't need to cature the print output at all.

I have worked out that the software is actually a bunch of executable "modules" so to speak. It seems (I haven't confirmed this yet) that for each screen that you can print from, a separate exe is being called (PRN????.EXE). This got me looking into how single invoices are printed to get an idea of how this all works.

To print an invoice, the main app calls "PRNINV.EXE". I've worked out that the command line contains -1 and the invoice number. (eg: "PRNINV.EXE -1148" = -1 and invoice 148.) I don't know if the -1 has any significance yet. (I'm assuming it's a reference to which database to open first.)

I have also found that the databases for this app are actually standard sequential files with a "DAT" extension. I should be able to read these as random files in VB with no problem, since all the fields appear to be strings.

It looks like everything is separate though; customer details, part numbers and descriptions, job descriptions, money paid etc are all in separate databases. There are 7 DAT files in the app's folder in total. If I'm thinking along the right lines, then each record in the invoice database, would contain references to the other databases. If so, I'll be able to work all this out in time.

I'm going to do some more poking around to see what the other print modules are receiving on the command line and what they are accessing. It now seems to me though, that grabbing the relevant data directly from the databases is the way to go, providing that we get the the references we need to start with on the command line. Being DOS, I really don't see how else it could be sent, as nothing is being sent on STDIN to the modules that I've looked at so far.

The main problem now: If I'm going to write code to read all the databases just to print all this stuff, maybe I should just write a whole new Windows app, and convert the seq files to proper databases. Hmmm, the mind boggles....

I'll keep this question open in the meantime, as I don't know yet if the original approach will still be required.

Anyone who wishes to comment, please feel free to do so. It would be handy to know how to capture the printer output from a DOS app anyway. In my research so far, I haven't been able to find a real answer except for certain "known" circumstances. The "real" world shall benefit from a "generic" solution.

Oops, I'm rambling on here, so I'll go. (...and get another beer.)


Be good. If you can't, don't get caught!

 

[BobRodes]

That PRNINV.EXE was what I was looking for. You should be able to do this:
[tt]PRNINV.EXE -1148 >myfile.txt[/tt]
which will redirect the output of the command to myfile.txt.

HTH

Bob