rclerk @once

[Brian K. White]

The version is 5.0.13 and 5.0.14. And @once works in rclerk in general, 
it just doesn't in this table.

The table in question has the odd property that it starts in @menu, does 
a pushkey U which sends it into @update (don't ask me why someone did it 
that way), and then the bulk of the table is actually all in @update, 
and then it exits completely out of rclerk while still in @update.

So, it would seem that despite the docs, @once comes after either @menu 
or @update or both, and this table exits before getting to the point 
where it would have run @once.

This destroys the easy rule I had been living by for years, that you can 
and should use @once to initialize variables (as in, set them to known 
explicit starting values, not declare them) and rand("-1") etc, because 
in fact you can not depend on @once always happening, or always 
happening before anything else. Instead the rule is now only "usually", 
and you always need to examine the code to ensure it will happen as you 
expect. This also means even for a table where the rule is true as 
usual, at any time some other programmer could make it not-true after 
the fact just by inserting or changing @menu or @update without 
realizing it will break something that depeds on @once.

-- 
bkw


On 7/31/2017 4:24 PM, Nancy Palmquist via Filepro-list wrote:
> Brian,
>
> I think I would certainly check the version of rclerk and dclerk you are
> using.  I recall that @once in clerk was not added at the same time it
> was in *report.  My Laura guide indicates it only is available in Clerk
> and says v5.0.  So it it is not working for you check the versions of
> rclerk, rcabe and dclerk to make sure all are at the same version.
>
> Nancy
>
> On 7/20/2017 6:07 PM, Brian K. White via Filepro-list wrote:
>> On 7/20/2017 4:14 PM, Scott Walker via Filepro-list wrote:
>>> Brian,
>>>
>>> According to Laura's Quick Reference Guide for filePro version 5.0 2nd
>>> edition
>>>
>>> @ONCE processing does come before @MENU and @UPDATE
>>>
>>> She has a great Inquire/Update/Add flowchart showing the order of things
>>> getting executed.
>>>
>>> If Laura gives me permission I would be glad to scan it and post it
>>> here,
>>> but I would need her permission.
>>>
>>> Her Quick Reference Guide is worth is weight in gold.
>>
>> Thanks for that info. We have her help files, maybe we have that too
>> and I just have to look around.
>>
>> And if it's as you say, then "Houston we gots a problem", because it
>> absolutely does not happen as claimed.
>>
>>
>> Not that I'll ever see any correction, because I'm on 5.0.14 and will
>> not be moving past that version, and they certainly will not be
>> issuing any bug fixes to it.
>>
>> So I've worked around it with a couple of ugly "if did_init ne Y then
>> gosub _init" at the top of both @menu and @update.
>>
>> Even the workaround is crap because it relies on did_init not being Y
>> on entering the table. Technically, you are not supposed to just
>> assume that fp had initialized all variables to null. You are supposed
>> to initialize them yourself before using them to make any decisions,
>> and the best place for that is @once, but since I have to use a
>> variable to emulate the very behavior of @once itself...
>>
>> It's an exceedingly fine point. It actually works fine, because a
>> variable generally IS initialized empty by fp. It's just technically
>> not right to actually rely on that assumption.
>>
>>> By the way,  thanks so much for your post about the libtermcap.so.2
>>> you use.
>>> It very much helped me today.
>>
>> Our pleasure. Fairlite put that rpm together, and that repo and
>> server, that we're using in production in the end. I don't know if he
>> submitted the fixes back upstream or not, but if not, I intend to
>> sooner or later myself, so eventually no one should need any special
>> home made rpm. I just haven't touched our migrate-to-centos project
>> recently.
>>
>