no input files message from printer file

[Scott Walker]

-----Original Message-----
From:
filepro-list-bounces+scottwalker=ramsystemscorp.com at lists.celestial.com
[mailto:filepro-list-bounces+scottwalker=ramsystemscorp.com at lists.celest
ial.com] On Behalf Of Fairlight
Sent: Sunday, January 06, 2008 1:11 PM
To: FilePro Mailing List
Subject: Re: no input files message from printer file

Simon--er, no...it was Barry Wiseman--said:
> That message is generated when filepro closes the pipe to lp to direct

> print output instead to your file.  I believe if you first issue a 
> "printer reset", then the "printer file" command, that will prevent
the 
> message.


Mark said:

I'm still not getting it.  I may not be the OP, but I don't see how any
of
the answers concerning "what has to be done to get lp to stop printing
that
message" have been relevant so far to his problem.  

FROM the docs:

     PRINTER FILE "filename"
                        Send output to file "filename".

I have used this feature myself on Windows 2003 Server with fP 5.0.14 to
send output directly to a file, do not pass Go, do not collect $200.
It's
then handled by PrintWiz to convert to PDF for download.

Key thing being, it does not even -attempt- to print anywhere but to
that
file, nor should it.  No spoolers, no programs--nothing except the file.

So far, I'm failing to see where `lp` or any other print spooler should
even remotely be in play while using PRINTER FILE.  Emphasis:
***FILE***.

Now, my very salient question is:  Why/How is `lp` getting called -at
all-
from PRINTER FILE?  When we know the answer to that, we'll have a
reasonable chance of providing a sane solution that works.  There are
only
a few ways I can think of this happening:

1) There's a bug in fP at whatever release the OP is using, and PRINTER
FILE is broken there, and does indeed try `lp`.  I kind of doubt this,
as
this feature goes back -at least- to one major version prior.  Pretty
sure
this was in 4.8, so I can't see it being left that buggy that long.

2) There's some sort of printout-inducing command that is getting
triggered
before or after PRINTER FILE, and it's a flaw in processing with a
drop-through (no END somewhere?) either before or after...somewhere.

3) It's a case of *report being called and using PRINTER FILE in a
process
table, and -that- goes to file, but *report thinks it should be printing
something to a printer for the current record or what have you.

Those are the three most logical explanations that come to my mind.

I just fail to see how multiple people telling someone how to fix lp is
helpful when lp shouldn't even be in play at all with this command.
It's
not addressing a primary root issue.

No flame intended...I just want to see Scott get a real answer, and none
of
the discussion so far seems to be headed in that direction.  At least
not
to me, it doesn't.

mark->



Scott says:

Mark, I may be mistaken but I seem to remember fp creating some empty
files and handing them to lp when you use the "printer" commands in
rreport.  I think I was told that what happens is by the time fp
encounters the "printer" command it has already opened a print file.

I seem to remember seeing this when I would use "printer name" on a prc
table, that was run with rreport, to change the printer that the report
would go to.  I would end up with (2) print jobs in the spooler.  One
was zero length.

I may be totally mis-remembering this but I thought it might be
relevant.

Regards,


Scott

Scott Walker
RAM Systems Corp.
ScottWalker at RAMSystemsCorp.com
Ph: (704) 896-6549

I