I think CCLINT has a point on what binding means to you. I have always thought of binding as setting up the control at design time and that's it. Maybe this is an outdated view. Probably because I don't bind controls and haven't for years. Why? I'm not sure, probably I have gotten too comfortable in using the same or similar controls in an unbound fashion. Maybe I haven't given the new VB bound controls a chance.
So, those who advocate binding controls enlighten me!
First, let me play devils advocate for a while. I have a problem with the following statement. "You can! control all! data going to and coming from bound controls, any time, every time, and mostly better and faster than any other way. And best of all, they do not have to even be bound to a database----until you! (not the control) are ready to get or send the data."
What does mostly mean? Is there an unbound method that is better and faster, if so why bother with binding the controls?
"And best of all, they do not have to even be bound to a database" Does this part of the statement advocate unbound controls? From my point of view if you are setting the datasource or recordsource property at runtime then the control is unbound, but that might just be my outdated view.
The bottom line is that I believe that there is a place for both binding and not binding. The question shouldn't be which is best but rather which best suits your current needs, or your current skill set.
Looking forward to your comments.
Thanks and Good Luck!
zemp