Gerry,
To quote from "Cool Hand Luke", "What we have here is a failure to communicate".

Two-way programming is not and should never be construed as only having text based source. Yes some other (if not all) development platforms that have implemented two-way programming have text source files but the two can't be linked together. The fact that the source files are text based may have made the implementation of two-way programming easier is irrelevant. What is also irrelevant to what I have been saying is the following:

1. Choice of editors
2. Choice of text utilities
3. Choice of source control

These have nothing to do with two-way programming.

What I have been saying from the start is that two-way programming is not dependent on having text-based source files. It seems from your statement below that you see that. Text-based source files add some benfits and the ones listed above are some of them. I did not get into this to debate the Pros and Cons of Text-based vs DBF-based source files. I only wanted to clear up what I thought was a discrepancy. I feel I have done that. If you (or someone) wants to start a thread on why source files should be text-based that would be great. If you want to use the fact that two-way implementation is easier due to this fact and you know it to be true, feel free. But don't go saying that it is the only way to implement it.

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

They were not framed in that context. They were framed in the context that it can't be done using any other type of source file. This was done because they were bringing in all the other "benefits" of text-based source files that had nothing to do with two-way programming.

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

We're only talking about two-way programming at this point (at least I am). I'm not talking about any other benefits that may or may not be appreciated using text-based files. As for paling by comparison, the Fox team is pretty good at anything they try and do. I wouldn't be surprised if they implemented a first-rate solution.

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

Then start a thread discussing the benfits of text-based source files (as I suggested earlier). E-mail your request to Foxwish@microsoft.com discussing those benefits. Who knows what would happen?

*snip*
>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 ?
>

I never said there was a problem with going text. With the exception that the entire VFP IDE would have to be overhauled to accomodate that effort, there isn't any. ;-) This may take resources away from other new functionality and that may detract from the idea.

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

Correct me if I am wrong but once you "use any editor", do you still have the ability to right-click and go to the text view? Does Delphi automatically launch your editor? Or are now effectively short-circuiting the Delphi IDE going off on your own?

*snip*
>The point was that a "utility" was required to solve the problem as originally posted in this thread.
>

The post that stated that a utility was needed was overkill (IMO). It didn't need this.

*snip*
>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" ?

I am using re-entrant in this context to mean that the designer can read changes you make outside of it. It doesn't care. For example, SQL Net Easy Configuration (ORAINST) is not re-entrant. It configures a text file (TNSNAMES.ORA) with information used to connect to various Oracle resources. It embeds something (chksum ??) in the file. If you change the file in a text editor and then try to bring it up in the SQL Net utility again, it will display a message saying that the file has been manipulated since the last time you used the utility and it wants to revert to that version. If you decline, you can't open the file using the utility.

Text-based does not necessarily mean re-entrant and you must have re-entrant for two-way programming to work.