>>IE. >>>>>>>>>> THERE IS NO VCX/SCX/MNX ! <<<<<<<<<<<<<<<<
>
>PMFJI, but why does the source file have to be a text file?
>
>IMO, VFP uses DBF files for its stuff because it is very fast with regard to this format. The routines are already there to parse a DBF file so the internal tools use them.
>
>You can have your two-way deal using the VCX/SCX as a table and simply adding/modifying the Methods/Properties fields as needed. If you want to add a new item, just add the record and modify the appropriate fields. if you want to position it (graphical item), then close the file and open it in the visual designer and make the necessary adjustments.
>
>Or have I missed the point of this thread too? :-)

You seem to be suggesting that one BROWSE the VCX and access the individual records and method fields; I don't consider this particularly attractive .... there is no continuity ... you're looking at small program units and cannot manage the class as a whole.

I would rather have the "option" of seeing the entire class "in code", making sweeping logic changes, saving the class, and then having everything show up in the "visual tool" (when I'm tweeking the UI) at a later time.

I've already "parsed" VCX's ... maintaining the object structures they represent "by hand" is not feasible.

Unless one has actually worked with a real 2-way tool (and had the need to crank out "a lot of code"), it may not be possible to visualize the difference. With Delphi, for example, it's simply a question of a right mouse click: "View as Code" (ie. a single text program) or "View as Form" (the "visuals") ... and make your changes in whatever mode is appropriate under the circumstances.

I've progressed thru line editors, full-screen editors, GUI interfaces and "2-way tools"; I know what I like, and it includes "2-way programming" with "text files" (and an IDE that knows the difference).

Then again, I find "Intelli-sense" irritating and turn it off at the first opportunity :)