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

[Kenneth Brody]

On 10/20/2010 1:08 AM, flowersoft at compuserve.com wrote:
>> Again, your "solution" to the problem is to simply not show the field,
>> rather than avoid the problem in the first place.
>
> What "problem"?

The problem of modifying a real field in automatic processing when not in 
update mode, thereby having one value of the field in memory, and a 
different one actually in the record, without updating the record.  Your 
"solution" is to say "I'm not showing that mismatched field, so the user 
never has to see that there's a problem here".

> Here are my instructions and code:
[...]
> Automatic (myauto) processing:
>
> 	If: @sk="brky"
>      Then: switchto 1; goto JUMP1
> 	If: @sn="9" and 5=""
>      Then: 5="Y"; end
> 	If: @sn="9" and 5="Y"
>      Then: 5=""; end
> JUMP1 If:	...		'other processing if any
>      Then:	...
> 	
>
> Input processing:
>
> @entsel  If: @sn="9"
> 	 Then: entsel=""; pushkey "b"; end
> 	   If: entsel="y"
> 	 Then: entsel=""; switchto 9; pushkey "b"; end
> 	   If:
> 	 Then: entsel="Y"
> 	   If:
> 	 Then: declare entsel(1,yesno,g)
> 	   If:
> 	 Then: ...		'other processing here if needed
>
> 7 lines of code.
>
> Could you please point to the line(s) that you think would cause a "problem" in this case?

Your code still modifies real field in automatic processing when not in 
update mode.  You then have convoluted logic to work around things and make 
sure the user never sees the wrong field 9 when doing your "only on screen 
9" code.

> Didn't you say "Actually, if you're not in update mode, then modifying real fields in automatic won't cause index problems, nor will there be a clash with more than one person viewing the record at the same time, because the changed data won't be written to the record."
>
> Since the user is never really in update mode, wouldn't the statement above be true?

You're not going to run into index or data corruption, but you still have 
the "field 5 is modified when not in update mode, and the changes won't be 
written to disk" issue, which you have "worked around" by simply making sure 
that the user doesn't get to see the mismatched field 5 value.

> Understand that I'm not advocating that it is OK to update real fields in automatic processing, just like I never advocated using "write" in automatic processing, although I did find it necessary to use it in one case to be able to accomplish what was needed.

If you're not advocating it, then why are you writing code that does it, and 
showing this code as a "solution" to the initial question?  Why not modify 
the field in input processing, where it belongs, and where you don't have to 
write convoluted code to work around the issue of modifying real fields in 
automatic?

> If I was tackling this problem I would have used the method you originally recommended, which was to do a browse lookup from the main file and handle it with processing.  Much cleaner, but that is not the solution he was asking for.

But, even with using "u" from a "real" browse, why do you insist on not 
modifying the field in input processing, from within update mode?

> He wanted a solution that would work from the regular browse screen and that is what I tried to give him.  His exact words were:
>> "I want to be highlighting a record and press a key (lets say "T") and have it check off the highlighted record (as in>checking off the items in your check book that have cleared).  So programmatically when you pressed "T" on the browse>screen, the highlighted record would have the value of it's "Cleared" field set to "Y" and the browse would be>refreshed so the "Cleared" field would now show "Y".

So modify the field from input processing, rather than automatic.

[...]
> I may be wrong, but I think the solution I posted does exactly what he wanted to do with very little coding effort.  Unless of course, you show me which part of the code would cause a "problem" in this scenario.
> And if you have a better solution (not a different one) that does exactly what he wanted to do, please post it.
> We are all here to learn, especially from the Grand Masters of filePro.

And, with even less code than you used to "work around" the problem of 
modifying the real field in automatic, you could put it where it belongs, in 
input processing.

-- 
Kenneth Brody