rclerk @once

[fP sales]

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.




On 7/31/2017 6:52 PM, Brian K. White via Filepro-list wrote:
> 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.
>



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20170801/d58a18ac/attachment.html>