Modifying real fields in automatic (was Re: Some Sort of ControlFrom The Browse Screen)

Kenneth Brody kenbrody at spamcop.net
Sun Oct 24 10:11:35 PDT 2010


On 10/23/2010 12:02 AM, flowersoft at compuserve.com wrote:
[...]
>> Oh, and as for only people using the -y myauto changing the value... What
> do
>> you think I meant?  Two people using normal processing?  :-)  I meant
>> everyone involved using your processing, do you want to state which person
>> will see the correct value or not in that case? That is the only scenario
>> that matters in this discussion, no?
>
> You got me there. I must admit that during those 15 minutes I did not
> anticipate that two or more individuals might be checking off the items that
> have cleared from the same checking account at the same time.
> However, if that were to be the case, my code would still work because the
> tree doesn't really fall unless the user presses "U". :-)

Well, to be fair, as I said earlier in this thread, the modifying of a real 
field in automatic is not going to cause data or index corruption(*) because 
filePro won't write the modified data!  But, the user will still see(+) a 
mismatch between what's on the screen and what's in the record.

However, given that you don't even care about the modified value, and you're 
only doing it "just in case" the user has pressed 'U', why don't you put it 
in input processing where it belongs?


(*)  Assuming you don't then have processing that, for example, uses the 
modified value and stores it someplace else, like a lookup file.

(+)  Unless you make sure to never let the user know about the mismatch.

-- 
Kenneth Brody


More information about the Filepro-list mailing list