Hi Craig,

Ahh, I understand, interesting concept... I have some doubts however.

1. Most things you describe can easily be implemented in the refresh event of the object

2. More importantly though is that the workings of the program are effected by these so called databindings, it easily could result in a situation where one is searching to no end where the bug is, not realizing that it has to do with databindings. IOW it is very easy to create an application where it is about impossible to track certain behaviour or problems, generating a kind of spagethi code structure.

Don't get me wrong, I think it could have some sensible application, however, I'd be very conservative to use it because it actually moves functionality from code into the specification of properties, meaning that the readability of the application could significantly decrease.

Walter,




>Hi Walter,

>Sure. For the example, I'll just describe the way VS.NET does it. In amongst the properties for an object (say a textbox on a form for instance), there is a section called DataBindings and you can click into the Advanced portion of that and a list of properties for the object will come up (forecolor, visible, size, text, enabled, etc.). From there you can bind these properties to a field in a dataset you've set up. So, just as in Visual FoxPro where setting the controlsource of a textbox to a field will cause the value of the textbox to dynamically change, you can have these other properties change based on the field they are bound to (receive their runtime value from).
>
>As for highlighting the benefits, I would say that it provides for very sophisticated and dynamic application managers to be set up. Nearly everything could get its value from a table/cursor at runtime, so the ability to dynamically change the behavior or appearance of the application would be super slick. Also, I think of security aspects of the application, such that certain controls enable/disable or become visible or invisible based on a user's security level and simple databinding that was setup at design time. Take it a step further and allow us to place complex expressions in for the bindings and you really have something (not just data, but now just about anything can be used as the controlsource for a particular property).
>
>Imagine triggers and rules in the database (that would be changing the data) dynamically changing the appearance or behavior of the application without having to write a bunch of code to do it. I think perhaps that the closest thing I can compare it to in Visual FoxPro is the dynamic properties of the column object. That has certain aspects that are pretty close to the same thing, however I'm talking about being able to databind to nearly every property (those that are write at runtime anyways) of every baseclass VFP has. Does this customer have a picture on file? No. Then make that picture box invisible and resize these other controls to fill-up the space. Does this user have a security level to see this customer's SSN#? No. Then make that label and textbox invisible. Can the user edit this record? No. then disable all of these controls. Dynamically change this label's caption, make the backcolor of that control red, the font setting in admin was just changed so now all the fonts show
> up tahoma instead of arial, the user has moved some controls around on the form to better fit their work habits so the settings for top and left have been saved in the fields they are bound to, etc. etc. I mean the list really could go on for days on this sort of thing.
>
>As I said, this can kind of be done in the subclasses that a developer has created for their application. But that's a buttload of code that would need to be written (in order to achieve this type of functionality), and changing the behavior from one form to the next would require further subclasses and/or more code. Around and around you go. The way VS.NET does it is far superior and there are lots of benefits to be had in productivity and dynamic control being able to set databindings like this (even more so if expression were allowed).
>
>This all having been said... Ken Levy already said, "No". So, there goes another stellar idea! <vbg> Though this sort of No hurts more than some, since this could only be done effectively in the core source.
>
>
>>Hi craig,
>>
>>>You've brought up a number of the issues I also would like to see addressed in .NET. However, on the databinding, I would like to see VFP take a page from the .NET book... I like being able to bind object properties. It would be super-cool to see Visual FoxPro allow for more than the single ControlSource property or at least be able to define what property the ControlSource effects (other than the Value property for instance). I'm not sure why that has never made it into Visual FoxPro... seems like it is a no-brainer and would make the basecontrols so much more powerful given the datacentric nature of Visual FoxPro. Oh well, I guess it can be done by developers manually in their subclasses somewhat (just not nearly as well as it could be done by the Fox Team in the source).
>>
>>I think, I'm lost here. Can you give an example of the above and highlight the benefit ?
>>
>>Walter,