Pertti -

(1) There have only been a few instances of the 'buffer overrun' problem reported to me. In one of those cases, I was sent the code and have been able to reproduce the problem on my own computer. (Curiously, on a laptop in SP1, but not a desktop in SP2!)

It is very hard to generalize from one instance.

So, while I agree that having to remember to switch back and forth would be tedious for those few experiencing this problem, I can't foresee that we will ever know enough about it to be able to predict it before it happens.

As for the debugger -- that's an issue that I've spent lots of time on. Since PEM Editor is, in fact, just a form, it slows down (a lot) just like all forms do when the debugger is running. You have two things you can do:

(a) Use the Preferences item which will automatically close debugger windows while PEM Editor is active (when disabled, they will be re-instated).

(b) You can also re-compile the project, turning off the 'debug info' under 'Project Information'. This is not done as part of the normal installation, since it means that it is not possible for users to report on bugs encountered during its execution.

Hope this helps,

Jim Nelson



>>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.
>>
>
>Just a thought: Is there a way to identify the problem classes automatically (i.e., is there a pattern within the class that could flag the different processing automatically)? Remembering to turn the manual option off and back on again when needed will use additional "brain cycles" and "attention energy," which is never a good thing -- those should be reserved for the work at hand.
>
>On another topic: Is there any way to avoid the significant slowdown with PEM Editor when the debugger is active? Not a show stopper like a buffer overrun crash, but an annoyance nevertheless.