Local Printing To PC or Thin Client - Final Resolution

[Dennis Malen]

Brian,

Thanks for your input. I take your last response very seriously and know
that you are only trying to help. You certainly are much more skilled in
filepro than I.

I was trying to solve a problem that pertained to one type of terminal
emulation and more particularly when someone is entering the system through
the web. At that point we know what their emulation is and this solved the
problem and it is fast.

I will try to absorb your suggestion which I am sure solves my problem
universally.

I am responding to you and to the list because I want to make it perfectly
clear to you and everyone else that I appreciate your comments which have
always been intuitive and helpful.

Please continue with the good work.

Sincerely,

Dennis Malen
516.479.5912

----- Original Message ----- 
From: "Brian K. White" <brian at aljex.com>
To: "filePro mailing list" <filepro-list at seaslug.org>
Sent: Thursday, January 06, 2005 7:02 PM
Subject: Re: Local Printing To PC or Thin Client - Final Resolution


>
> ----- 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
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>
>