rclerk @once

[Brian K. White]

On 8/1/2017 6:18 AM, fP sales wrote:
> 5.0.14 readme
>
>
> Note: Although @ONCE in *report is documented as being run prior to any
> output being done, it was run while sitting on the last record read
> during the sort/select process prior to release 5.0.14. Some people
> thought that this meant that it was sitting on a selected record.
>
> @ONCE has now been fixed to be not sitting on any record. However, some
> people depend on their incorrect interpretation of the old behavior, so
> setting PFOLDONCE=ON will "revert back" to a modified version of the old
> behavior, where it will now be run while sitting on the last record
> _selected_ during the sort/select process.

Interesting, but none of that applies.

* This is clerk not report.

* I do not expect @once to be sitting on any record, and the problem 
description didn't include any reference to records or real fields.

Although, there is a "lookup - r=free" followed by pushkey U in @menu. 
So the table does move to a record and work on it, but that is unrelated 
as far as I can tell. The problem isn't that I expected to be on some 
other record. The problem is that @once never gets executed at all. 
(well, also specifically that it didn't get executed before everything else)

Another "Although", simply because it's a change to @once at all, in 
that same version, maybe it's indirectly related by being a clue to some 
possible yet-undocumented behavior.

I'll make a distilled example table to just show it.

....and my distilled table works as documented and expected. Of course 
that would happen. :)


So there must be more details involved in my actually malfunctioning 
table, which is a non-interactive cgi process that is run by another 
non-interactive cgi process, so it will take me a few minutes to rig up 
something to capture the actual command line and data passed to it to 
replicate the full exact conditions.

For pointless reference, the distilled table which I expected to fail 
was just:

prc.at_once_bug

:' Exhibit @once bug in *clerk 5.0.14:' @once exists in this table, but 
is never executed.:
:' rclerk filename -S0 -z at_once_bug -y NoAuto:' 20170801 brian at aljex.com:
@menu:'***::
::msgbox "In @menu^A did_at_once=\""&did_at_once&"\"":
::lookup - r=free -e:
::pushkey "U":
::end:
@update:'***::
::msgbox "In @update^A did_at_once=\""&did_at_once&"\"":
::exit:
::end:
@once:'***::
::did_at_once = "Y":
::end:
::declare did_at_once(1,,g):

This is the order these sections appear in the real table too. For 
instance, just like here, in the real table there is no "end" or "exit" 
at the top to prevent unexpected fall-through into @menu, in case the 
large wandering @update code branched somewhere and didn't exit rclerk.

When I put the same sort of implementation in the real table, I did NOT 
get a "Y" here:

rclerk filename -S0 -z at_once_bug -y NoAuto

┌───────────────────────────┐
│ In @menu: did_at_once="Y" │
└─────────── Press  Enter   ┘

But this does, so, until I can show a reproducible example...
I am curious now. This really should be an equivalent example of the 
table that shows the problem.

-- 
bkw