>>>>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.
>>>
>>>PS: You could work on VCX as if it were a prg if you directly use the vcx table and edit properties/methods fields and then compile.
>>>Cetin
>>
>>You are saying "non-visual"... I don't know if it is the same, maybe not, but I built my Business Object classes based on the Custom class when I addded them to the VCX. Is that "non-visual"? Either way, that's what I have, and I use PEM Editor to work on them. It basically gives me a nice way to work on the Properties and Methods that exist in each class.
>>
>>.
>
>Custom is a VISUAL class. Column, header, session ... are non-visual classes.
>Cetin

Either way, all this terminology of what is "visual" and what is "non-visual" is a distraction from the actual issue I raised...

Which, to recap, is:

"I wish there were a (1) reliable, (2) efficient, quick, seemless way to (3) fully round-trip (4) any/all VFP classes (5) from a VCX to PRG and/or from PRG to VCX."

That's it.... Just 5 simple steps which meet 100% of the above stated features.


.