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.
Jim Nelson
Newbury Park, CA