rclerk @once

[Nancy Palmquist]

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.
>

-- 
Nancy Palmquist         MOS & filePro Training Available
Virtual Software Systems    Web Based Training and Consulting
PHONE: (412) 835-9417           Web site:  http://www.vss3.com