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

I actually ran into this myself when com interop events are firing. Is there anyway to disable the com events from firing while you are doing this? Or can you unload them and do a clean disposal and then reinstantiate them? I work with a dotnet dll that fires events in my vfp app (VFP 9 sp1) and on some error handling this occurs when the com interop events fire while doing any type of memory dump in the error handler.

Just a thought...