>>>>>This is a follow-up to the thread Error Record out of Range.
>>>>>
>>>>>I think Christian Isberner correctly wrote that the error possibly is triggered by either Clear Events or Quit or Cancel. But how do I log the problem is not clear.
>>>>>
>>>>>First, please confirm that I understand the sequence of events correctly. The program issues READ EVENTS at the top.
>>>>>Then, whenever the program calls CLEAR EVENTS, the code goes to the first line after READ EVENTS. Correct?
>>>>>
>>>>>Then, how do I log, after READ EVENTS, that a problem occurred? Or how do I log, before READ EVENTS, that the problem was caused by CLEAR EVENTS?
>>>>
>>>>
>>>>A 'record out of range' is not always trappable on a specific line. The first thing to do it to have a TRY CATCH around your READ EVENTS and use ASTACKINFO to capture information about where it occurs. In our case we have identified the error is sometimes trapped in the READ EVENTS line itself and therefore not caused by a specific line, but rather related to a cascade of firing events.
>>>>
>>>>In most cases we could track the cause back to grids. If you are using grids to enter data, it is possible that code in a valid event causing the record pointer to change causes the issue.
>>>>Another notorious one is the use of indexes with grids where you enter data, especially in the column where the index is based upon.
>>>>
>>>>Any code that is in the event loop (like refresh) might cause the issue if it implicitely or explicitely changes the recordpointer.
>>>>
>>>>Its a nasty one to debug. We have managed to eliminate most of them, but once in a while, we see one at the error log at clients. At least with the TRY CATCH around the READ EVENTS, it does not crash our application and the user can just continue to use the application.
>>>>
>>>>
>>>>Walter,
>>>
>>>Yes, I agree, this one is very tricky to duplicate or troubleshoot. I was thinking about putting the READ EVENTS inside a TRY CATCH but I was concerned that it may crash the app. Good to know that you already tested this approach and found that it would not crash the app. I will try this approach, probably just on a customer or two that do get this "nasty" issue.
>>>Thank you.
>>
>>I suppose this is the only read events in the application? First of all I am not sure why that is in a do while loop.
>>Any code after clear events should not be necessary. The code where it checks for Destroy and loops and goes back to read events is problematic. I would do this just before CLEAR EVENTS and issue Clear events only when successful.
>>
>>In theory a program is very simple:
>>
>>SET commands..
>>Create application main object
>>READ EVENTS
>>RETURN .T.
>>
>>When closing the program, do all cleanup first and then issue Clear Events:
>>
>>Application.quit():
>>
>>Success = Close all forms (return .t. if a form cannot close, ask for save etc...)
>>IF Success
>> Success = Do any checks: Can we quit?
>>ENDIF
>>
>>IF SUCCESS
>> CLEAR EVENTS
>>ELSE
>> Keep running.
>>ENDIF
>>
>>To solve a problem that you cannot debug you can use Refactor To Understand. I would imagine getting rid of the loop and move the destroy to clear events would be less effort than to find the real error. Hopefully this will either solve the error or make it easier to debug.
>
>I have the DO WHILE since many years ago. And since it worked form 99.9% of the cases I am reluctant to remove it. Even though it may not be the perfect approach.
>
>I just checked my app (using gofish) and I have only one READ EVENTS. But I have a few CLEAR EVENTS. And I also have in the Main.prg (before the READ EVENTS fires) the line
>

>on shutdown clear events
>

>
>From what Walter said I gather that the problem is not how the READ EVENTS or the code before and after fires, but with something else in my code or program.


Correct,

As I we found in our cases, the error was caused in the VFP event model and especially with tables/cursors with indexes in combination with grids, the error could only be trapped on the READ EVENTS.
One correction though... (Sorry I got this wrong). We are using ON ERROR to catch the error on the READ EVENTS. In all other places we use TRY CATCH. I can't remember there was a specific reason for that.


We got something like this (It actually is a bit more complicated than that because of other reasons)

DO WHILE .T.
	_lError = .F.	

	_tax_cOldError = ON("ERROR")
	ON ERROR DO HandleError WITH ERROR( ), MESSAGE( ), MESSAGE(1), PROGRAM( ), LINENO( )

	READ EVENTS

	ON ERROR &_tax_cOldError
	IF _lError = .F.
		EXIT
	ENDIF
ENDDO

If in the error routine you set the _lError valirable to .T., you can catch the out of range error, display a message to the user, but continue the app without crashing out.


Walter,