>I agree that it stands in the way of visual coding, but that is because
>VFP uses the table structure in its visual component. I think you said
>yourself that to be OO one should be able to tie objects to the GUI, no?

I am not sure what it is u say I said :)

anyway -it doesn't have to stand in the way of visual programming if the other "visual" componenet will be able to work with these dataobjects

>So ... would you not agree that 'Visuality' stands somehow in the way of
>pure OO at this stage in VFP?

"visual" programming and prototyping are to help you develop more rapidly as I said somwehere else OO is not about this.
OO mixes with RAD mainly in the sense that OO helps increase reusability
but they colide on other "matters"

>> , this is btw, one of the reasons I use DEs as seperate object so I can have forms that uses more than one "table setup"
>> and naturally only the instantiations are data specific
>> I think this will only slow VFP without much gain
>
>Well from what I see, what I would do is not so different form DE,
>because what is a DE if it is not a combination of 'my' tableBase
>classes.
DEs are not what u talk about (or at least not what I think u talk about) in the sense that although they separate the open/close relations etc. from the rest of the form they don't isolate the table from the code
if i use a DE I still seek directly in the table -

I find using DEs (as separate object from the form) enough
I don't think that going for that extra trouble will add too much in robustness as my classes are "table independant" as is