You have a good point. It seems your team did the did the heavy listing (a detailed design plan) up front to assure the highest value. And, if Marcia was involved (time with Marcia would do us all good!), I am sure your project has no seams and executes like a rolex.

Your solution for line item entry using a grid is a sensible service for your requirement.

It is overly complicated to "label edit" a listview row. There is another grid object, the flexgrid. I saw a piece of one of Jordan's interfaces that implemented a flexgrid. It was enjoyably tastful!

There are also situations where textbox entry is prefered. Especially in highvolumn entry where a kind of rythm is established by the clerks entering the data . The app can feed the lines to a listview. That way, when they reconcile or correct, they visually verify their entries and select any they may require edit change.

But I do projects for system houses or get calls at the tail end of projects in trouble. I've seen projects that cost 6 months of man hours and all that could be shown was a form with buttons and pretty bmps in the buttons (it was a VB project - so we can't blame it all on the fox!).

I've seen projects with no design. If the "developer" eventually bumbled into another data requirement, he/she would just shove another grid on the desktop - sometimes even using the raw field names for column headers. And I am sure many of us have seen those FP2.6 projects that [have] remained FP2.6 through all the VFP versions!

The issue the market has with foxpro is not because of shops like yours that solve a line entry requirement with a well executed grid implementation. It because a bunch of so and so's that did not care (had no pride in their work), or did not know enough to do the design, were selling themselves as VFP developers during the hey-daze of the 90's. And my point is that one remedy for our success is to shy away from grids when they're not needed. Or substitute a listview or treeview for those cases where "navigation" is the primary task.

We need to refrain from the willy-nilly of (as John stated: 85% grids) and challenge ourselves to use the active x controls. I did not really begin to learn OOP till I begain my learning curve with OCX (and I am still learning). And once I began to understand OOP a bit better - a whole new side of VFP became available.

With VFP we can mimic any data application we've seen on our desktop or in movies. I've seen 007 GUIs in the "oil patch". These are really sophisticated apps. VFP could build those interfaces - even connect to realtime "points".

The UT magazine had a three part case study where foxpro was the core of an automated transit system! Heck - look at ACC-PAC, ABRA - Ed Hardin's bulk mail system - VFP is one of the most versital inventions in the world and some are doing quite well with it.

Some say - its not a web interface. Who cares. Look around. Our economy is moving towards a cottage economy. Sure - the cottages will need a web presence to sell their merchandise or take web orders - but these are services already in the can on "u-rent-um" servers. VFP will be needed inside the cottage to count beans and automate operations.

Cottage business don't need all the expense of DBAs and security (if anything - the web will be less secure except to those with the "really" big bucks). They just want to count their beans. The LAN is still doing good. VFP is great for LAN projects. VFP could be great for almost any project - but first, we as developers need to challenge ourselevs. If our projects lack sex-appeal in VFP - then they will lack sex-appeal regardless of tool. And, as you know, sex-appeal sells software!:)