>>The historical: Until VFP made it possible to turn off data-binding in a form, it was a royal PITA to try to bind controls to data in a flexible fashion. If the data didn't exist when the form loaded, all the controls would unbind themselves. Even though there's now a way to unbind and bind controls flexibly, I still have to support Win 95 so I have to stick with VFP 7.
>
>This was a problem but could be worked around by loading data through a form control. This is now thankfuly much easier since VFP 8.
>
>>
>>The design issue: When you bind data to controls, that tightly couples data to GUI. This causes two problems:
>
>Yeah of course it does. Databinding is your connection point between data and GUI. Where else are you going to have that? The alternative is to manually bind and then what? How do you get notified in manual binding that a value has changed? One way or another you have to implement that.

My baseclass controls have a property called "IsForData" and when it's set to .T., they will pass a message up the containership hiearchy if the user changes what's being displayed by them. When this message reaches the form level, a form property called "DataChanged" gets set to .T. My business classes also contain code to detect whether such a "change" is real--that is, did the new value end up being different from the old value? A save operation only occurs if there was a real change to at least one field.

The other issue here that I should have mentioned: Non-specific data applications. My current project involves quite a bit of user-configurable data-driven stuff. I don't know at design-time what specific items of data a user is going to want to display and enter, and there isn't always going to be a one-item-one-field correspondence for this data. So it's really less work for me to write "manual" data transport code than to try to write code that will work with VFP's RAD features.

>>1. Data validation: Data validation must be done in a user-friendly fashion. Cryptic messages about broken field rules in the database aren't helpful. And if controls are bound to data (even when it's a temporary middle layer between the GUI and the back end), then when the user enters bad data it immediately goes to the controlsource, from which you'll have to remove it. My business classes put validation between the data-entry controls and the business object; if the data's bad, it never gets sent to the controlsource and never has to be removed from it.
>
>
>>2. If you need to present the same data in different ways in different forms, you have to keep rebinding all those controls. I deal with this differently. All of my GUI forms have a single standard interface that a business object can access to read data off a form and transport it to the back end. And the business objects have a single standard interface that the GUI can access to pull data in for display. The business object knows nothing about the names, or even the classes, of the GUI display controls. And the GUI knows nothing about the data objects or tables the business object pulls from. To me, this flexibility has been worth the effort it took to develop the base classes.
>
>I agree. Actually to some degree what you describe is very close to how the new .NET 2.0 databinding manager works - it's a separate object that acts as the interface between the UI and the data. You can choose to use the default binding mechanism or hook all the events and manage it yourself including dealing with errors...
>
>Still this is considerably more work and for most developers who build applications this is overhead that is useless to them as they don't implement these sort of rules in the first place.

Yup. As mentioned above, though, I already have many hoops to jump through to provide flexible user-configurable systems, so this extra work is actually the line of least resistance for me.