>As far as I can see, Ed Rauh's solution is of the type 'rawprint'. A series of bytes is rawly sent to the printer (spooler) and control characters should already be in that series of bytes.
>
>My initial 'solution' to my problem was:
>
>- Optionally let the user call sys(1037) to choose another printer and/or change the printer's settings:
>
>
> set printer to
> sys(1037)
>
>
>- Find out what printer is in use:
>
>
> if empty( set( 'print', 1 ) )
> lcSelectedPrinter = set( 'print', 3 )
> else
> lcSelectedPrinter = set( 'print', 1 )
> endif
>
>
>- Send the (let's say 3) reports to files:
>
>
> lcPath = addbs( sys( 2023 ) )
> report form x1 to file ( lcPath + 'MRP_1.TMP' )
> ...
> report form x2 to file ( lcPath + 'MRP_2.TMP' )
> ...
> report form x3 to file ( lcPath + 'MRP_3.TMP' )
>
>
>- Concatenate the files to a single file:
>
>
> lcPath = addbs( sys( 2023 ) )
> lnFnd = adir( laTempfile, lcPath + 'MRP_???.TMP' )
> lcC = ''
>
> for ln = 1 to lnFnd
> lcFile = laTempfile[ ln, 1 ]
> lcC = lcC + filetostr( lcPath + lcFile )
> next
>
> lcFile = 'MRP____.TMP'
> strtofile( lcC, lcPath + lcFile )
>
>
>- Send that single file raw (!) to the printer
>
>
> * Source: Universal Thread
> * Parm 2 also occurs in aNetResources( aa,{computername}, 0 ) if it's shared.
> * Parm2 is a port or UNC.
> * returns 0 if failed
> DECLARE INTEGER CopyFile IN KERNEL32.DLL ;
> STRING @SourceFileName, ;
> STRING @DestFileName, ;
> INTEGER bFailIfExists
>
> if copyfile( lcPath + lcFile, lcSelectedPrinter, 0 ) = 0
>
> messagebox( "Printing to '" + lcSelectedPrinter + "' failed." )
> endif
>>
>This is essentially the same as Ed Rauh's class does.. I think.
>
Actually, it's not in a number of circumstances; DIRPRTCLASS was written to get around problems related to certain types of print queue errors, and to execute in an asynchronous fashion (if you look back in the FAQ and WinAPI sections, you'll find I did the writeup on CopyFile() as well.) DIRPRTCLASS actually creates a spool queue entry rather than copying the content of a file to a port or UNC, which can create problems in certain spooler situations like some versions of the NetWare client introduce, or if you want to address a printer that isn't identified by either a DOS port name or UNC, but instead by a Windows Printer name. It's not a pure isomorph of RAWPRINT.VCX, either, which uses some of the same API calls, but has a different interface philosophy.
IAC, both CopyFile() and DIRPRTCLASS use writes to the target printer that avoid the interposing of the GDI in the process; one works at the port level and the other at the spooler level.
>Note that each file will have printer control codes on board. Those codes are determined by the printer in use at the moment that REPORT FORM is called. The design works perfect as long as one is printing to ..indeed.. a printer.
>
>However, when we direct output to the fax (the option in the Docuprinter's setup, realized through sys(1037) ) then the REPORT FORM x TO FILE generates NO FILE! And as a consequence the concatenation of nothing also generates nothing to fax.
You could use the MS-supplied Fax Printer driver used by MS Fax to format output prepared for output to a file and then take the files and queue them to the Docuprinter - this is the approach I take here at home to concatenate files into a single fax document for output through my Canon MultiPASS L6000 to fax rather than print.
>
>I imagine that Ed's solution will give the same complication.
>
>Further reflections are very welcome!
