> No, it isn't a native VFP error. VFP is written in MS c++ so the > undelying libraries have MS c++ error messages. When a pointer > references a memory location outside of the space allocated for vfp, c++ > generates this error. It's a boiler plate message; it never changes and > it never gives any additional information.
Yes-- I'm primarily making sure it's created by the VFP process and not something you're observing through a c++ debugger you've attached to the process or anything. > No flls or api calls in the app. You are using API calls in Ed's setmemory.prg. What O/S are you running under? interpretted and/or compiled? Have you commented Ed's setmemory.prg to see if that's causing the issue? I'm curious, considering you're bringing it up-- unless it's the cause, it shouldn't matter-- a buffer over-run is an error in code and shouldn't be related to available memory whatsoever. Have you been able to narrow it down to any part of your code? I've had many VFP functions with known buffer overrun problems, such as TEXTMERGE() in VFP7. There was a work-around then that you can pass the string with a chr(0) at the end(effectively zero-terminating the c++ buffer properly). I wrote simple Z() and NZ() functions for this purpose-- adding and removing the trailing nulls.. -- Derek _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
