>Howdy all --
>
>I have given this problem additional thought, trying to find a workaround that will help those who keep getting blown away by these frustrating 'Buffer Overrun" problems.
>
>I do not think we can find a way to correct the actual problem, merely a way to avoid getting blown out of VFP.
>
>So, I have a proposal for those who are having this problem. It involves providing the capability to temporarily disable a small part of PEM Editor while working on these problem classes, as follows:
>
>
>There would be a new option in Preferences, a checkbox which would be used only for those classes experiencing 'Buffer Overruns'.
>
>When this checkbox is checked on, PEM Editor will skip the statement causing the Buffer Overruns will be skipped.
>
>The effect of this will be that PEM Editor will not display the descriptions for PEMs -- in fact, in will not even allow you to enter descriptions.
>
>
>The idea here is to temporarily cripple PEM Editor (just a bit), so that most of its functionality is still available. Thus, you'd want to turn this switch off again when working on all other classes.
>
>There is one drawback -- you will have to know which classes will cause this problem and change this flag BEFORE opening the class -- as you know, PEM Editor will croak as soon as you open the class.
>
>Any thoughts on whether this would be a satisfactory workaround for this problem?

Here's a brute-force, possible way to get around the need to know, in advance, which classes cause problems.

Spawn a separate VFP process, and have that process try to run the code on the problem class. If the process gets killed by Windows, you know it's a problem class. Otherwise, gracefully end the temp VFP process and open the class with full functionality in your main VFP process.