>>With the powerful features of PEM Editor (filtering by property/method name, sorting, viewing parent code, etc.) I find that my productivity of working on even Non-Visual classes is much faster when working in a VCX.
>>
>>So, I cannot adopt your preference for keeping Custom classes in a PRG. I am too spolied with PEM Editor. However, I will admit that there *are* times that I wish I could temporarily work on the VCX in a PRG, just for a few certain tasks, and then come right back to the VCX.
>>
>>Maybe one day!
>>.
>
>I think I will stick with native editor:)
>How do you work on non-visuals in a VCX? I vaguely remember I could add non-visuals to a VCX in very old times but I forgot how I could do it. Would you remind.

Using a builder - create an aSelObj() reference to the object being edited, then .newobject(...) the non-visual member to it. However, you must have the .prg where the member is defined in the Set Procedure if you want to open that class with a non-visual member again. IOW, it can be done, but it's more trouble than it's worth. I prefer to add prg-defined members at runtime; sometimes I place a shape as a placeholder on the form/container/page, and in the shape's .init() I .newobject() the member to shape's parent, set its position and size to that of the shape, then return .f. so the shape is gone.