Local Printing To PC or Thin Client - Final Resolution

[Brian K. White]

----- Original Message ----- 
From: "Dennis Malen" <dmalen at malen.com>
To: <filepro-list at lists.celestial.com>
Sent: Thursday, January 06, 2005 5:26 PM
Subject: Fw: Local Printing To PC or Thin Client - Final Resolution


>
> ----- Original Message ----- 
> From: "Dennis Malen" <dmalen at malen.com>
> To: "Brian K. White" <brian at aljex.com>; "filePro mailing list"
> <filepro-list at seaslug.org>
> Sent: Thursday, January 06, 2005 12:58 PM
> Subject: Re: Local Printing To PC or Thin Client - Final Resolution
>
>
>> Brian,
>>
>> I never respond with a resolution unless it works. It is only after it is
>> tested that I share that info.
>>
>> It works perfectly with one page or multi page reports. We are using this
>> for our managers who log into our system through the web. It's great!
>>
>> We have also developed another approach which is to run the report 
>> through
>> processing i.e. using "system". This allows us to check the type of
> terminal
>> and to change the initiation and termination codes on the fly.
>>
>> What you would do is to set up different executable files that have code
>> similar to the following:
>>
>> echo "\033[5i"
>> cat $1
>> echo "\033[4i"

Unlike the print code table method, this will work OK since filepro is 
suspended and does not write anything to the screen while the system command 
is running.
rreport however DOES write to the screen after having issued the init 
printer code and before the end of the report sometimes, depending on how 
your report happens to be written.

Completely aside from that, you are hard coding ansi printer codes in a 
place that should not be making any such assumption.
Even the script above makes that assumption. Really you should have mc4 and 
mc5 in your systems terminfo (as well as PN & PS in termcap) and the script 
should ideally look like:

tput mc5
cat $@
tput mc4

That allows terminfo to supply the right printer control codes, if any, 
regardless of term type, if terminfo has been set up right, and allows 
multiple filenames to print at once, and even allows spaces in the 
filenames. You may not need any of that, but look at it, it's no more work 
to do it the way that is very flexible and will "just work" even in lots of 
odd cases than it was to do it the way that only works in one special case.

The correct way is to put the PN & PS into either your system or fp termcap 
files and then fp will send the PN & PS codes possibly many times during one 
report so that any time rreport wants to draw on the screen, it knows to 
send the printer-off code first, display the msgbox or whatever, then send 
the printer-on code and some more print data.

You don't want to do it that way? Your code just doesn't happen to do any of 
the perfectly legal things that might conflict with the way you are doing 
it? All your terminals happen to be ansi and understand the same printer 
control code? Fine, go ahead and keep doing it that way.

But I am telling you it's not correct and will fail in many situations and 
so it is not right to advise others to do it.

Lest you think I'm just one of those who likes to criticize instead of be 
helpful, I'll sit here or in the voice room and spend 2 hours of my time and 
help you get it the right way if you want, but if you don't want, that's 
fine. Just take my word for it that it's wrong, as gospel handed down from 
someone who, just as the tiniest example, knows how to escape some quote 
marks in a system command in his sleep.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani