>>Doing this makes your report hardware dependent - if you are forced to run the report on say an HP LaserJet, the HP's native codes will not match, so Windows will map the native Epson fonts to a near-equivalent Windows font and render it as graphics, and in all probability, the printed image will not be identical to the output on the Epson.
>
>
>Ed,
>
>Printing "text mode" makes me hardware dependent, but this is a price I pay for speed. You need to send specific printer codes to reset the printer, print bold, etc.
>
>??? will send printer codes, and the actual reports, to the printer.
>
>? and ?? can be used to generate the text report. Other programmers use @...say, instead.
>
>The text report can be shown on screen with MODIFY COMMAND, but this causes problems because of syntax highlighting. I used NotePad.exe, then Programmer's File Editor, and currently the default browser (this lets the user see bold and italic). Use the PRE tag to avoid line-wrap, and to use a fixed-width font (this trick I learned on the UT, without actually asking!).
>
>I created an entire class to duplicate report-writer funcionality: break (or grouping) expressions (header and footers for each break level), page headers, etc. Basically, in method .Select() I insert commands to do the data selection, a main loop is run for each record. When the group expression(s) change, methods .GroupHeader() and .GroupFooter() are called with appropriate parameters.
>

I have a far better set of tools that I use to handle direct printing to the spooler, bypassing the GDI entirely, and with the capability of of directly assigning files to the spooler, disabling the normal Windows printer behaviors of forcing the printer state to a new page, forcing skip to top of fresh page, etc, which I use, along with a couple of ActiveX controls for handling specialized printer products without invoking or involving the GDI. If there's enough interest in release of a class that directly manipulates the spooler through the API without involving creation of hDCs (it works purely with hPrinters) and bypassing normal Windows/spooler paper handling behavior via StartDocPrinter()/StartPagePrinter()/WritePrinter()/EndPagePrinter()/EndDocPrinter()/AddJob()/ScheduleJob(), I could probably release a version that's in source form, and has been fairly heavily tested, but is reliant on my CLSHeap() memory management class and is not going to be a high priority as far as providing others with support. I've released it to a small group of people who have not reported any problems in a number of environments.