If you're concerned about performance, another option is to spawn the secondary VFP process when you start the PEM Editor. Then it would be available for immediate use. With modern multi-core CPUs and sufficient RAM, the performance hit might not even be too noticeable.

Maybe you could combine this with your Preferences/Checkbox idea i.e. let the user choose to run the PEM editor in standard mode (the default), or a fault-tolerant mode.

>Al --
>
>I think that might kill any responsiveness from PEM Editor, no? This only occurs, after all, for a few users, and then for only a few classes of theirs.
>
>>>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.