printer file "name" - problem
Dennis Malen
dmalen at malen.com
Thu Mar 17 11:39:10 PST 2005
Brian,
I reviewed your comments and I find that my processing has everything you
suggested except for :
system noredraw "umask 0;>"<fn
Is this line necessary and why?
I still need the PUTENV, as I only want the heading to be printed once. I am
only executing that command once, unless it doesn't matter. I do know that
PRINTER FILE (per Ken) must only be executed once. I'm not clear on whether
PRINTER TYPE needs to be only once. If someone would clarify that, it would
be appreciated.
Once I get this clarified I will post the final results on what works. It is
evident that this is not clear to everyone. This is what the list is all
about.
Everyone's responses are very much appreciated.
Dennis
----- Original Message -----
From: "Brian K. White" <brian at aljex.com>
To: "filePro mailing list" <filepro-list at seaslug.org>
Sent: Wednesday, March 16, 2005 6:20 PM
Subject: Re: printer file "name" - problem
>
> ----- Original Message -----
> From: "Dennis Malen" <dmalen at malen.com>
> To: <filepro-list at lists.celestial.com>
> Sent: Wednesday, March 16, 2005 3:43 PM
> Subject: Fw: printer file "name" - problem
>
>
>> Now that the list has died down I will resubmit this problem as I never
>> received any clear cut answers.
>>
>> It really is a two part question, I will only submit part I.
>>
>> Is there any way to override in "rreport" format a printer that is
>> defined? Ken will ask me what is defined mean! The printer is defined in
>> Extended Function under Options. The processing below does not do it. Ken
>> will ask me, "Do what?". It does not allow the ASCII file to be written
>> to the disk.
>>
>> This problem is not necessarily directed to Ken.
>>
>> Dennis Malen
>> 516.479.5912
>>
>> ----- Original Message -----
>> From: "Dennis Malen" <dmalen at malen.com>
>> To: <filepro-list at lists.celestial.com>
>> Sent: Monday, March 14, 2005 2:38 PM
>> Subject: printer file "name" - problem
>>
>>
>>> Problem: In order to create a PRINTER FILE "/tmp/anyname" I am using the
>>> processing below. The initial problem was that I had to take out the
>>> definition of the current printer in the report form I was using. I
>>> could not keep the definition and override it with PRINTER TYPE
>>> "nocodes". I could get by that problem (but its a pain to copy over the
>>> report format and take it out).
>>>
>>> The next problem that arose is that when I viewed the file that had been
>>> created each record selected was a full screen. I then changed the
>>> number of lines of the report from 64 lines per page to one line per
>>> page. I also changed the heading so that only one line appeared. That
>>> worked fine. I don't think that is how PRINTER FILE "anyname" was
>>> intended. I should be able to create a viewable ascii file without
>>> having to do what I did.
>>>
>>> WHAT AM I DOING WRONG???????
>>>
>>>
>>> Then: pa(1,*,g)
>>> - - - - - - -
>>> If: pa=""
>>> Then: PUTENV "FPONEHEAD","on"
>
> This has no effect. You are already in rreport and rreport has already
> made its' one and only pass through the environment to look for such
> variables to modify it's own behaviour.
> The only thing this would affect is if you next has a system command that
> ran rreport, that child instance of rreport would behave according to
> PFONEHEAD.
>
>
>>> - - - - - - -
>>> If: pa=""
>>> Then: printer type "nocodes"
>>> - - - - - - -
>>> If: pa=""
>>> Then: printer file "/tmp/dailydep"
>>>
>>> - - - - - - - -
>>>
>>> Then:pa="p";end
>
> OK so you are ensuring that this only ever gets run one time, that is
> good.
>
>>> - - - - - - - -
>>> @done" If:
>>> Then: system "cat /tmp/dailydep|pg";end
>
> If you intend to work with the file while still actually in rreport, then
> you most likely need to actively close the file in a way you wouldn't
> otherwise need to. If this pg command had been outside of processing in a
> new line after the rreport line in a menu batch script, it'd probably have
> worked, except for one other thing, which is ownership & permissions.
>
> Whenever you are creating a file with filepro, and then needing to work
> with the file outside of filepro (and "ouside" includes system commands
> within processing) then you always need to pre-create the file with
> permissions and ownership that you will require later, and then let
> filepro write to the already existing empty file. In that case fp won't
> change the existing files properties, but if fp creates a file itself,
> then it's owned by user "filepro" and other users can't write to it or
> delete it, possibly not even read it in some cases.
>
> So, if you really need to use system commands within report for this, then
> you need 2, one at the very beginning right with the printer type and
> printer file commands, and whatever you want in @done like you have
> already.
>
> Since you now have to refer to the file at least 3 times, it should be a
> variable, and since you have @done, I think that automatically means you
> have @once, and so you should use that instead of performing those tests
> on every record, so rather than edit above, I'll just put the whole new
> thing below:
>
>
> if: ' main report body
> then: ' ....
> if:
> then: end
> @once if:
> then: fn(255,*,g)="/tmp/dailyrep"
> if:
> then: system noredraw "umask 0 ; >" < fn
> if:
> then: printer type "nocodes"
> if:
> then: printer file fn
> if:
> then: end
> @done if:
> then: printer flush
> if:
> then: system "pg" < fn
> if:
> end:
>
> For pfonehead you simply must set this in the env before entering rreport.
> No other way to set it. Use F5 to make the menu action line into a script
> and insert a line above rreport:
>
> PFONEHEAD=ON ; export PFONEHEAD
> rreport ...
>
> There is actually a neat, single-line syntax for this that would allow you
> to just edit the menu action line like so:
> PFONEHEAD=ON rreport ...
> (note, no semicolon and no export command)
> But not everything that you can do in a script or at the command line
> works on a runmenu action line so even though it's still just one line,
> you may need to make it into a script to work. I don't remember offhand if
> this would work or not.
>
> (although I had time for this, I still don't have time to post that code.
> It's full of assumptions and relies on external scripts & utils that our
> boxes always have but that I'd have to describe in some deatil to anyone
> else, or else rewrite it into something more self-contained, which I have
> little interest in doing since it wouldn't even be any better for me)
>
> .... blah, got distracted by someone and forgot I had this mail almost
> ready to send hours ago.
>
> 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
>
>
>
More information about the Filepro-list
mailing list