get clerk to act like report

[Brian K. White]

tldr: "-n"

On 4/4/2013 10:44 AM, Kenneth Brody wrote:
> On 4/4/2013 4:57 AM, Brian K. White wrote:
>> I want to run a report that just calls a call table once for each record.
>>
>> Except in that call table I want to issue form commands, so I need clerk
>> not report. Or else I need report with system clerk commands just to do
>> the forms, which I would rather avoid.
>
> Am I correct that different records may print different forms?
> (Otherwise, you could just run the form in *report.)

Exactly, except there's also another reason. It is true that I may want 
to output different forms on different records, and also output a few 
different forms on *each* record.

But also this call will usually be called from a regular user 
interactive input process. So it needs to work from input processing, so 
"form" not "print", even if I was only using one form always.

>> Records are selected via selection set. So the main input processing is
>> just one line to call the call table. Except that by itself doesn't
>> actually work.   It just sits there at entsel on the first record.
>
> That's because if the prc consists solely of that CALL, then it's not
> triggered until you come out of update mode.
>
> (Also, the above could have been simplified by simply making the called
> table the input table.)

Except I want it as a call for a few different reasons. See above.

Except, "what happened when I tried it(tm)" is you are also right of 
course, at least in this particular case, which is partly just 
happenstance. See below.


>> If I make the table:
>> ---top---
>> end
>> @entsel
>> call "mytable"
>> end
>> ---end---
>>
>> Then I can walk the records and the call table runs on each, by pressing
>> enter. But that's no good and I can't believe that adding a pushkey is
>> really the answer either :)
>
> That should work, though it is a bit kludgy.

Exactly, which is why I never really considered it.

> Note that, if the selection set is pre-built, you could also use the
> "-xs" flag to assist, as it would automatically exit dclerk if you press
> Enter on the last record.
>
>> So how can I construct an input processing and clerk command line
>> options so that clerk will essentially behave as report and run once per
>> selected record and then exit at the end of the selected records?
>
> One possibility that comes to mind is to use the selection set to build
> a demand index.  Then use lookup-dash to traverse that index, printing
> the forms along the way.

Howie my secret personal resident ace in the hole filepro expert dinged 
me with the clue.

"-n"

So my "input" process just has one single line:

---top---
call "mycalltable"
---end---

And my command line is:
rclerk file -z myinput -Sblankscreen -XS myselectionset -n

And it works. Selects and runs just like report ziiiip.
(I intentionally want the normal auto proc to run because it supplies 
stuff for the forms.)

But wait it gets better and you already knew it...

Sure enough the call table also functions when executed directly by -z 
instead of call. This works:

rclerk file -z mycalltable -Sblankscreen -XS myselectionset -n

The one-line -z myinput above is not needed.

The call table uses only long variables and an exclusive namespace. 
Every variable in the table has a foo_ prefix so none will collide with 
anything in any other input or auto table. This makes it safe to use as 
a call, but doesn't hurt anything when executed directly by -z.

I could very easily have needed to do input-only stuff before/after the 
call, like @once/@done stuff. In that case I would need the separate 
input table, or else I'd have to do something extra in the call table to 
emulate those triggers, and to detect the difference between running as 
input and running as call. But in this case since I don't happen to need 
anything other than the call table itself, it works. That's not 
automatically true in any other situation.

So thanks everyone and thanks Howie.

-- 
bkw