>>My opinion, and my opinion only < grin > is that this would be awesome. I hate mucking with VCX/SCX files. Having it text based would make things so much easier.
>>
>>Michelle
>>
>Me too,
>Two-way tools would be a huge improvement - vfp is not a code generator, in my opinion the vcx, mnx, frx, etc. just obfuscate matters.
>
>Digressing, I think it has been obvious that Criag (with regard to two-way tools) has been talking out the wrong orifice all along! I also think George Tasker is wrong to state (even in parenthesis) what the vast majority 'might' want.

-----------------------------------
even more, i don't think it really matters what the "vast majority" might want. a development environment should provide alternate methods for doing things.

i see people in these threads refer to directly modifying underlying (form)tables as "hacking" ... i would say that is only because in the beginning and 90+ percent of the time, you don't have to go directly to the tables. (and because it was perhaps not the original intent). if you had started using jbuilder, where it was just as common to make changes in the text file as it was to make changes graphically, you wouldn't think of it as "hacking" ... just two equally viable options for making changes. and what kind of changes you are making determine which method was more suitable. as much as i like the "two-way" jbuilder environment, it is not completely intelligent and has its aggravations. e.g. if you create code graphically, go in and edit it textually (aligning, grouping functionality, etc), when you make changes graphically again, it will re-arrange your text-based edits. and have you ever looked at the form-equivalent code generated by the microsoft visual c++ environment. talk about some gross code !! and don't you dare change parts of it !!

as for vfp, why only "two-way" ? why not be able to move seamlessly between table-stored form info and text-based ? who would write that ? microsoft ? one of us (who has a lot of spare time on their hands) ? what would the text look like ? xml ? function (method) definitions ? maybe replace the form designer with a graphical representation of the classes, and the actual "form gui designer" would only be a little sub-branch used to actually position controls on the form. who wants to take a big step backwards and position controls on a screen by specifying coordinates ?
----------------------------------------------