Hi Jim

>So, how do you open it if you don't have anything open on the VFP Desktop?

I just DO c:\path\path\StartPEMEditor.prg from the command window

>I only know of two ways of opening it -- from the system menu, when you're editing a form or class, or from the command line. In both of these cases, I have something open on the VFP desktop, right?

yes, but you can just DO the generated startpemeditor and it does start, albeit blank, obviously.

>So what are you doing to open it?

DOing the startpemeditor.prg

>Other issues you mentioned:
>
>(1) Blanking of PEMEditor ... this behavior will be corrected in release 3.01. (No release date for that yet). This has nothing to do with the screen position.

Thanks, though I had not put it up as a issue, but yes a faster timer could refresh the PEMed when I am opening and closing classes without closing PEMed

>(2) Removing _MemberData to speed things up. A number of people have spoken of this. Yes, it's unfortunate that the implementation of such a desirable feature would cause such degradation.

Thanks.

Two more.

1) I was not able to open PEMed or rather VFP C5ed after/during opening a OLEBoundControl class of mine.

2) I don't know why and it never happened for other Containers, but one container I edited when I was resetting to default / removing _memberdata would just not allow removal of this property from PEMed (I can't delete from the VFP Properties window, it has to open PEMed for me to do this and PEMed in this case only wouldn't). No there was no _memberdata in the parent of this Container class, ie _memberdata started from this container.

I had to hack the vcx to remove the _memberdata for both the above cases. In regards to the above 2 issues, if we could override PEMed, by for eg. Shift-clicking the menu option, and getting the original VFP dialog, so such problem classes can still be dealt with atleast immediately until a bug report is filed back to you.

Hope I was able to explain.