>I'm wondering if you are having a limited view of databinding in downplaying its importance. Are you talking about the problems with databinding controls directly to the data table itself?
>
>Certainly Rick is not advocating that approach.

I am not talking about technical issues related to binding controls to data. I am speaking to isssues related to how our reliance on "binds" limits how we solve an interface problem.

What I am talking about is the breadth (sp?) of our design paridigms. A textbox can be bound to field - A rowsource for a list box can be bound to a table of fields. A grid is a snap to rowsource to a file!

What are the short comings of binding in this manner? How does a developer's reliance on these kinds of "binds" affect the way the project is delivered.
How does a reliance on "Table Buffering" affect the way we write apps? What are the limits of how an interface can be solved when we rely (or only use) bindings and 'macro' engines like table buffering.

I'll start a short list - if you rowsource, instead of additem to list controls, you loose the ability to drag and drop. With table buffering interfaces the is a tendacy to write one file forms. In those kinds of projects there are usually a plethora (i had to say it) of cascading modal forms that ultimately drill down to "the" form that initiates an action.

If you rely on rowsource binding - there is a high likelyhood that you would refrain from OCX navigators (tree and list) because OCX list navigators are not bound - they require discrete instructions to populate. It's not big deal - unless we refrain because binding is so much easier. The result - our projects end up wordy, formy, temp file monsters - they end up ugly.

Have you ever heard a VFP developer brag that "the" project is sevveral hundred thousands of lines of code, has 100 DBFs and 200 forms? When I hear that I immediately assume its an ugly, sexless grand mother of an application. The least dedicated among us always seem to turn into size queens!:-)

The market has been having problems with VFP - not because of VFP's potential - but because many of us use binding and grids and modal cascades - and then - we have the gall to tell the users that they have to follow some rules to use it.

I may be in a different market than most - but my users don't want rules, don't want instructions and don't want to deal with granny apps.

Now we have the Code Campers and the NOT Converters pitching NOT (and of course their tier tools, their seminars and "how to's for dummies" and their mastery of the words of the "newest world order").

Any VFP developer that is firmly planted in data binding (grids, lists and boxes) will have a very hard time moving away from VFP.

Blaming VFP for a bad design - and then believing those bad design strategies will somehow be overcome with the "New NOT World Order" platform is a bit like believing a severed finger will grow back. It won't happen.

I say this - if you think your app will be better in anyother language than VFP, let someone who prides themselves in sexy applications take a look at it before you switch to another platform.

As far as Rick and Data Binding - he may read the specs - but lets face it - Rick aint sitting around writting full blown accounting or bean counter apps (with big integrated data requirements) and evaluating their performance. He's marketing his NOT tools with his associates marketing NOT training and "conversion" (what is that?) service.

His tools have wizards - and the wizards are cool - but they are a far cry from a high end bean counter and are not subject to enduser critques - most end users would not know if a wwc product was bolted to their system (and most wouldn't care!).

Any notion Rick has about data binding is limited to how he uses it in his products. For Rick to make a judgement on data binding and then suggest that judgement applies to the way all problems are solved is a bit of an over reach.

For example - a recent thread asks about the Active X Inet Control - has some specific questions about it. Rick responds the the OCX Inet sucks and suggest the poster check his product out. Rick is wrong - Inet works - it works fine - and the poster does not need to use Rick's solution.

Words like "codey" and "hard to debug" are meaningless to someone who wants to roll his own. And here, on the UT, we have Mr. Strahl, who could certainly advise the poster on the issues with Inet OCX, instead bad mouths the OCX and reccomends his stuff.

People - half the fun of this business is building something and then watching it work. If we know how to help a poster get some functionality out of VFP/MS packaged control - lets help them do it - lets help them accomplish it - to fabricate a fact ("Inet OCX sucks") and then , in the same sentence say "but mine does not", is obnoxious.

Rick - and all you other marqee suits and marqee wanna be's - have you forgot how much fun and satisfaction there is in making those detailed technical pieces of a project work? Have you all grown into sour pussed republicans that can't give an honest minute unless there's something in it for you?

Are you guys getting too old for us?:-)