I'm one not so worried about VFP becoming a "walking dead" -- for unique reasons.

(1) I'll be 65 then ...

(2) In my previous career, I worked in a language, APL, that was clinically dead about 1985. I survived (full time job!) until 2003.

>Thanks, Jim.
>
>I applaud your efforts to improve VFP, though (heh -- at this rate VFP could well become a "walking dead" beyond 2015...) This utility is great in many aspects, so it may still be worth the tradeoff for many.
>
>
>Pertti
>
>>Howdy Pertti --
>>
>>Yes, we all get used to the tools that work for us and we get comfortable with them. Tis indeed unfortunate for those who normally have the debugger open that PEM Editor's performance is so slow -- asking people to make a significant change in their behavior to accommodate a new tool is asking too much.
>>
>>Jim
>>
>
>>>>Hi Pertti.
>>>>
>>>>>It is a big enough drag having to remember to close the debugger every time I use the PEM editor that I'd rather not use the PEM editor at all, even if it has some really nice features.
>>>>
>>>>Just curious: PEM Editor is a design-time tool and the debugger is really a run-time tool (by run-time, I don't mean in an EXE but executing some VFP code). Why leave the debugger open at design-time? I usually open the debugger only when I need it because having it open slows everything down.
>>>
>>>It is just a habit when I do a lot of development in one sitting. I set breakpoints and watch points and debugout statements etc and it is a drag when especially breakpoints sometimes disappear when I close the debugger and then reopen it. VFP debugger is not exactly what I would call a "consistently re-entrant" program...
>>>
>>>Of course I could save debugger settings before closing it and then loading them back again upon reactivation, but by then you are asking an old dog to remember too many new tricks and the already creaky wrists and hands to do too many clicks just to accommodate a somewhat fancier PEM editor.
>>>
>>>Pertti