>>>>>>>>>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.
>>>>
>>>>That could be the issue, because the On Shutdown sequence combined with Clear Events may make the code that is happening between difficult to trace.
>>>>
>>>>what about trying to get more control by running a procedure in between:
>>>>
>>>>ON SHUTDOWN do QuitProgram
>>>>
>>>>QuitProgram():
>>>>
>>>>Optionally check everything
>>>>
>>>>if success
>>>> clear events
>>>>endif
>>>
>>>Your approach of a procedure in between is probably better approach; overall. But I am not sure that it would help finding those rare cases of "Error record out of range." Or maybe yes. I don't know. Again, so far, I am reluctant to change the way the program starts or quits, simply because it could break something all together.
>>>Thank you.
>>
>>It could help because the problem may be that the on shutdown sequence calling the clear events sequence may make the code untraceable. The reason why something is working for 30+ years has never kept me from refactoring, and until now I never regretted it. I prefer to have total control and perfect knowledge what each line of code does.
>>
>>The paradigm "Don't fix what's not broken" does take situations into account that are difficult to maintain or difficult to understand. "Broken" does not necessary mean a program error must be present. And apparently even though the code is working, there is an issue that you are facing. Although the culprit is only a theory at the moment, it is the next best guess you have so far. So you have to treat the patient like Dr House would, just apply medicine to find the diagnosis or to rule it out. Either way you will be one step further.
>
>I have never watched Dr house or any other medical shows. But I read a number of medical books (I love those). And I have learned that sometimes the "cure could be worse than the disease" And I thank you for your input; I am carefully reading and "listening" to the advice. I am just not ready to start the surgery :)