>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.

I do not believe anyone who is familiar with "2-way" (and I'm specifically refering to Delphi, Vdb, VB, etc. ... all of which also happen to save as "text") considers using a "source file as a table" (ie. hacking a VCX) as "2-way".

The posts were framed in that context; not some abstract concept.

>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.

It might be "2-way", but it would be pale compared to the other implementations that use "text" since you still would be limited in your choice of editors, text utilities and Source Control Systems.

Nobody here is ignorant of the fact that the "source" doesn't have to be "text"; some of us just don't see the point of doing it any other way.

>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.

It "should" happen if you want a half-decent implementation. What's the attraction of VCX's anyway ? And what's the problem with going text ?

>> Since Delphi is controlling it, the source could just as easily be in encrypted binary files. <<

Well, it isn't and you can use any editor; you don't have to use the Delphi IDE.

>>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 point was that a "utility" was required to solve the problem as originally posted in this thread.

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

What does "re-entrant" have to do with it ? This isn't about multi-threading. Or are you talking about the "programmer" using the "design tool" ?