Board index » delphi » re-redirect-LST?

re-redirect-LST?

Hello.
I tried to play a little with the turbo pascal 7.0.
 As you know, we can redirect from the printer to a file. This is very
useful under  developing programs, that write huge amounts of data to
printer, because the tecnique  saves paper and time, and it is easier to let
a file browser ( eg the pascal editor )  find the topics in the print, you
want to study in details.
But how do I get back to the paper printer in the same session?

I played a little with the following code.
If you try yourself, be sure there is no file 'kamilla.grl' or 'lst' that
contains information uou wont loose, the will be overwritten.

uses printer;
const FF =3D #12;
      hello =3D ' Goddag   ';
begin
  { writeln(lst,hello+ff); {just to see it works on the printer}
  assign(lst,'kamilla.grl');
  rewrite(lst);
  writeln(lst,hello+'this is printed to the file named kamilla.grl, OK');
  close(lst);
{   writeln(lst,hello+ff); {just to see it works on the printer,
        but here it will make 'File not open for output}

  {now an attempt to get the lst back to the paper printer}
  assign(lst,'lst'); {this sequence will not, I know}
  rewrite(lst);      {but what else?}
  writeln(lst,hello+'this is printed to the file named lst., but that is not
intended'+ff);
  close(lst); {changing 'lst' to '' redirects to the CRT}

end.

Who knows??

Nils J=F8rgensen.

 

Re:re-redirect-LST?


Quote
In article <1996Nov19.083522.13...@arl.mil> nils joergensen wrote:
>Hello.
>I tried to play a little with the turbo pascal 7.0.
> As you know, we can redirect from the printer to a file. This is very
>useful under  developing programs, that write huge amounts of data to
>printer, because the tecnique  saves paper and time, and it is easier to let
>a file browser ( eg the pascal editor )  find the topics in the print, you
>want to study in details.
>But how do I get back to the paper printer in the same session?

>I played a little with the following code.
>If you try yourself, be sure there is no file 'kamilla.grl' or 'lst' that
>contains information uou wont loose, the will be overwritten.

The problem with your solution is that you actually open and
close the file.  This will have varying effects depending
upon the system.  Under a network, this would probably close
the capture file which would then be set to the print queue.  
When the file is reopened, a new capture file is created.  
The resulting output could then be scattered among many other
print jobs.

One solution that comes to mind is the disable and enable
codes that could be sent to an old Epson FX series printer.
If your printer has such a feature, it might prove to be
the easiest solution.

If you want to be able to turn printing on and off within a
program you might consider writing a TFDD (Text File Device
Driver).  This would allow you to use normal Write and
Writeln statements.  The routine that turns print output off
could check the flow state, and if it is ON it could flush
the existing buffer and set the flow-state off.  The routine
that enables printing could check the flow-state, and if OFF,
it would flush the existing buffer, then set the flow-state
ON.  The flush routine would also examine the flow-state, and
if ON would send the buffer to DOS. Regardless of the state,
the routine would always reset the buffer.

Of course you could also implement the flow-control within the
Flush routine and control output with a set of embedded
enable/disable characters similar to the old Epson. This last
method would be best limited to text output, otherwise you
would need a printer specific driver that could monitor the
output stream in order to determine if the characters where
really flow control, or part of a graphic.

    ...red

Other Threads