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

[flowersoft at compuserve.com]

I didn't put it in input processing because I didn't want other users to be
affected by the code and still wanted the user toggling field 5 to be able
to actually modify other parts of the record if he/she wanted to.  I was
doing that by allowing the user to hit "break" from the browse and then put
them on screen 1.
Since you can only detect @sk="brky" from automatic when not at an input
statement, that's where I put the 3 lines of code.  No one will ever be
affected by those 3 lines of code except that user.  In input processing,
everyone would have been exposed to the code and I would not have been able
to take the user out of the browse and unto screen 1 by trapping the break
key.
Maybe I could have found ways to do all this from input but I only spent 15
minutes or so coming up with the code.  At that time, I didn't want to make
it my life's work, I just wanted to give him a quick solution to the problem
he was facing without asking him to use a totally different method or just
that it could not be done.

Your argument is that it is wrong because it is just wrong to assign values
to real fields from automatic processing in general.  That's like saying
that guns are bad because they kill people.  My argument is that yes, maybe
guns are bad because they kill people but you prove otherwise, in this
particular case the gun is not loaded and the safety is "on". :-)



-----Original Message----- 
From: Kenneth Brody [mailto:kenbrody at spamcop.net] 
Sent: Wednesday, October 20, 2010 9:51 AM
To: flowersoft at compuserve.com
Cc: filepro-list at lists.celestial.com
Subject: Re: Modifying real fields in automatic (was Re: Some Sort of
Control From The Browse Screen)

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