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

[flowersoft at compuserve.com]

> Again, your "solution" to the problem is to simply not show the field, 
> rather than avoid the problem in the first place.
> Kenneth Brody

What "problem"?

Here are my instructions and code:

Create a screen 9.  Screen 9 should be a screen with no fields on it, just a blank screen.

The menu line: \fp\rclerk filename -s9 -xi -b "your_browse_format_should_show_field 5" -y myauto

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?

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?

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

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

>I'm pretty sure this can't be done but if anyone has a wild & crazy way they've made it happen, I'd love to know.

>I could even live with, when on the browse screen, press "U" and go into update on the screen.  Maybe I could take >over at that point, change the Cleared field to "Y" and then record the screen and go back to the browse
>screen.   But how would I tell that I had been on the browse and pressed "U"?"

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.