>>>>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.
.
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only