>>>I've recently added a fairly simple error handler to an existing application. The error handler, connected to ON ERROR, just collects info about the error and dumps it into a table, then gives the user some choice about what to do.
>>>
>>>In my simple testing, it works fine, but in some cases, it's causing a buffer overrun that's crashing VFP. The line where it crashes is LIST MEMORY. Here's the code up to and including a few lines after the crash:
>>>
>>>

>>>LPARAMETERS tWhen, cWhere, nLine
>>>
>>>LOCAL aErrorInfo[1]
>>>
>>>AERROR(aErrorInfo)
>>>
>>>* Log the data, including the call stack, into the
>>>* ONERROR table. Also, construct a message to the user.
>>>
>>>LOCAL cStackInfo, nStackLevels, aStackData[1], nStackLevel	
>>>
>>>cStackInfo = ""
>>>nStackLevels = ASTACKINFO(aStackData)
>>>FOR nStackLevel = 1 TO m.nStackLevels
>>>	cStackInfo = m.cStackInfo + ;
>>>	             "  Level: " + TRANSFORM(aStackData[m.nStackLevel, 1]) + CHR(13) + CHR(10) + ;
>>>	             "   File: " + aStackData[m.nStackLevel, 2] + CHR(13) + CHR(10) + ;
>>>	             "   Module/Object: " + aStackData[m.nStackLevel, 3] + CHR(13) + CHR(10) + ;
>>>	             "   Line: " + TRANSFORM(aStackData[m.nStackLevel, 5]) + ;
>>>	             ": " + aStackData[m.nStackLevel, 6] + CHR(13) + CHR(10)
>>>ENDFOR
>>>
>>>LOCAL cOldSafety, cMemFile, cStatFile
>>>cOldSafety = SET("Safety")
>>>SET SAFETY OFF 
>>>cMemFile = FORCEPATH("ListMemo.txt", SYS(2023))
>>>LIST MEMORY TO (m.cMemFile) NOCONSOLE 
>>>cStatFile = FORCEPATH("ListStatus.txt", SYS(2023))
>>>LIST STATUS TO (m.cStatFile) NOCONSOLE 
>>>SET SAFETY &cOldSafety
>>>

>>>
>>>The one twist here is that this application is working with a bunch of VFP-based COM objects. They get instantiated pretty early, and in fact, I've seen at least one case where I can put an error in after that and I don't get the buffer overrun.
>>>
>>>It appears that the difference may be whether I have READ EVENTS in effect. If I stick an error in right before or right after READ EVENTS, the error handler works as expected. If I introduce an error in code that will run with READ EVENTS in effect, I get the crash.
>>>
>>>Anybody have any suggestions? For now, of course, I'm commenting that part of the code out, so that I can test other things, but I'd really like to have the memory and status info in the error log.
>>
>>I came back to this today and found a solution. It turns out that the problem goes away if I remove NOCONSOLE from the command. Since my app is running in a top-level window, I came up with a solution that makes the main VFP window "visible" off-screen, allowing the listing to scroll in it, and then hides it again.
>>
>
>Unfortunately, while the solution worked inside the app in a simple test, I'm getting the same buffer overrun when an error occurs farther in. I haven't yet been able to come up with a simple repro case.
>
>If anybody's faced this one, either successfully or not, I'd love to hear about it. Maybe comparing notes about what's going on would help.
>
>Tamar

I have a fairly robust error handler for VFP that I built/updated over about a decade.

IIRC I set print to a file and then list memory and most everything else to the file. Then I roll the file into a memo variable (in the VFP version) or into a varchar(MAX) field in the SQL version.

I can't access my VFP development machine from here (client site) or I'd send you the PRG.

If you still need it this evening I can send you what I have.