encruypted>>>If we had two-way tools this would simply be a case of cut-and-paste. For those that have not quite grasped what two-way tools are about, please see today's thread "Life is Beautiful for PRG Based Classes" started by Mark McCasland (Message #524299).
>>
>>Hi Houston,
>>I'll say this again. <s> This is what can be done with txt-based source files. This is not an example of two-way programming (something entirely different).
>
>"Text" is the repository of "2-way".

Text is a respository of "2-way", not the repository. Two-way programming can be achieved using any singular source file. As I said once before, modifying the source from outside of the visual designer can be done using the source file as a table. The changes are reflected the next time you open the source in the visual designer.

VFP does not have this ability be default. Someone could probably design something to do this using the VFP data engine. Or the Fox team could add it a future release using the internals. Either way would still implement two-way programming.

What does not bave to happen is the conversion of source files to text source files. This is not a requirement for two-way programming. I don't know why some think it is. Yes, it makes modifications of source files easier from outside the IDE, but that is also not a requirement for two-way programming.

I believe it was brought up in another thread that two-way programming is achieved in Delphi by a simple right-click. That may be true but you are still in the Delphi IDE when the programming window comes up. The source is controlled by Delphi at all times so the source doesn't have to be ASCII based. Since Delphi is controlling it, the source could just as easily be in encrypted binary files. The same functionality could be achieved in VFP if the editing takes place in VFP. It is simply a matter of changing the interface we are used to (however simple that us < s >).

>THIS particular "problem" would have been solved in 2-way by "text editing" the "old" class, changing the class definition, and then saving (again as "text") to the new class.
>
>No intermediate "utility program".
>

No intermediate utility needs to be used at all in this particular case.

>The new class, can now be accessed in the "visual view" of the design tool, if need be.
>
>Why is this not an example of 2-way ?

Two-way programming requires that the designer be re-entrant, that's all this is an example of.