>Hi Rick.
>
>>The LIST MEMORY command you are using does not list the full contents of all memory variables. Using SAVE TO will store the full strings. It may prevent the buffer overrun error you are getting, and can be restored and parsed later to see the full set of variables at the time of the crash.
>
>I hadn't thought of using SAVE TO in an error handler. It *is* a pain that LIST MEMORY cuts off the value of string variables. So, I tried it and found one deal-breaking flaw: while LIST MEMORY lists all memory variables, SAVE TO only lists those currently in scope (IOW, in the error handler itself). So, it doesn't really work in an error handling situation.


That's unexpected. I have used the SAVE TO in a code logging function I developed which is called from original source code that was modified programmatically to insert logging call lines. If an original line said "llFoo = .t." then it would call the logging function before that line with one of the parameters being the current program, line number, and source code, and in that logging function it saves all variables to disk using SAVE TO. They appear properly saved and I have written tools based off of that data set, including a post-mortem debugger which allows me to run the logging process, and then synchronize between two instances of the application that were logged separately to scan for variances. I used it originally to identify issues between FPW 2.6 and VFP9 when porting old apps.

Sounds like something distinct/unique is happening there with the ON ERROR condition. Possibly a data environment issue?? I don't know. UPDATE: I looked back on my code, and I had it setup to execute the SAVE TO environment before doing the call to the logging function by introducing two lines for every original one source code line (three actually, but that's neither here nor there :-)). So, it was in the proper context. Sorry for the confusion, Doug and Tamor. :-)

I have written a utility to parse out the saved memory file without having to load it back into context in VFP which may be of some use at some point. See https://github.com/RickCHodgin/SaveToParser and the test\ directory.

I actually use the real-time conversions from those two mem files (as were saved when logged at each source code line) to find differences between the two apps. It helped me track mismatched event firings as compared to the old style FPW 2.6 .spr files, etc.