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

I will keep thinking and carefully testing for finding the solution.

Thank you.