Hi Hector ---

Look at John Peterson's examples here on the UT Files Section dealing with ADO.


>
> That sounds like the right answer. But I always fell like I am loosing many of the VFP features using that technique.
>
> Could you give more details (perhaps examples) on how to bind the UI to a dataservices type of custom object's properties?
>
>
>>Hector ----
>>
>>I don't see how you're losing much if you bind the UI to a dataservices type of custom object's properties (maybe the new Session object?) rather than binding direct to DBFs.
>>
>>
>>>I created a class to process 'Work Order Items'. Nothing special: quantity, item, price and total.
>>>
>>>My class has a property for the alias, so it can work with several different alias. The class assumes that the field names are going to be the SAME in any alias that I use. This make the class very limited. Not as reusable as I would like.
>>>
>>>Now, lets make the field names dynamic as well. I added 4 more properties to let the programmer specify the field names. Now everything needs to be defined in the properties and I lost all the visual stuff from VFP.
>>>
>>>Now, to get the item name and item price I need to look another tables. Hum, here we have the same problem. The look up tables needs to have the same structure for all the instances that pretend to use this class (or I need to make everything a property to let VFP redirect at run time.)
>>>
>>>Shouldn't I been working with objects and forget about the underlying structure (tables structures)? After all I can just add Load and Save methods to my classes and put there the table-specific code. That will make me an truly-OO guy. Well that also will make me lost a lot of the VFP database capabilities at some points (the code executed between the Load and Save methods - and there will be a lot of code.)
>>>reusability)
>>>
>>>So, I have 2 options:
>>> * Be truly-OO and lost VFP database capabilities
>>> * Use VFP database capabilities and forget about reusability (true
>>>
>>>Which one is the better? Why?