Hey Terry,
Since you poked my name in there I'd like to add few cents.
Hope you didn't mean me saying "con artists calling themselves VFP consultants". I think grids are more valuable than a treeview. My grid mentality never caused a market loss but gain. Strange observation on our part. If TV is the right tool then .Net should be praised more as .Net TV class is much much better than the ocx one.
Cetin


>I cannot understand why are you so fascinated with treeviews,
>and why you think they should be widely used to 'enrich' our interface patterns.
>I am more fasinated with "why" users of VB applications (and technical writers) felt that VB GUI's were more appealing than VFP GUIs. The reason was that VFP developers were selling grid solutions for every project. VB developers did not.
>
>VFP lost a lot of market because of the "grid" mentality and con artists calling themselves VFP consultants.
>
>I went through the "grid" phase. At first the grids were input controls - then they were navigators. Then users began to recognize VFP apps because they saw a grid. VFP's negatives are all associated with projects that overly relied on grids. With SQL it realy got noticable when we took the easy way with grid presented remote views.
>
>If you only know grids (or other bindable controls) you will loose when you compete against me - you will loose when you compete aginst non-VFP developers that don't have grids - but do use OCX.
>
>Not all data are hierarchical
>All data is heiarchial - subsets or the master list can appear as "flat" - but if data were not hierarchial - then we would not need procedural languages - a spread sheet would do.
>
>so unless there is screaming need/must/request why should we use them ?
>Users feel like they're being cheated when we sell them a grid solution. They already have Office on their desktop - thus they have Excel - if they wanted a spread sheet - they could have done it themselves with excel.
>
>Grids should not be used for data entry unless the data is norrwly scoped tavbular stuff - like the monthly average ambient temperature and wind speed for a give region.
>
>To navigate use a Listview (or a treeview / listview service similar to Explorer - the listview sliders are realtime - snap to is so yesterday - the data is cached and you can sort on on any column withou an index!
>
>Plus - you get to learn the other OCX controls - like the OLE container - imagelist - etc.
>
>With OCX you learn "node" scripting. There is a big world outside the XML2Cursor VFP world - the node experiencd from OCX translates to DOMDocument quite nicely.
>
>>What is wrong with (smart) grid to search/select records accompanied with 2-3 buttons like Add,Edit,Delete - HotKeyed and backed up by apropriate
>>grid-rightclick shotcut-menu options?
>Nothing's wrong with that as long as the solution is used to store granny's cookie recipies.
>
>When was the last time you speke with a prospect regarding an update to a VFP project. I met with a sop a few weeks back. The app was a maintenance app fro big ticket energy assets. It was all driven by right clicks on a treeview. For once I was proud to know the VFP developer that deleivered their current app used OCX. Those people asked me for a reccomendation for a VFP developer that they could hire to add some more features.
>
>Could I have picked you - probably not - OCX are not defficult - but grid projects rely on SQL selects - those kinds of developers loose their "iterative" point skills and have no idea what to do when they need to add a node. But OCX does require practice and record pointer skills. It's not something you can learn in one night - ask Tracy - Jim Nelson - or Cetin or the many other that are using treeview and listview. You have have to put at least a few months of spare time into understanding how to work with node collections. If you only do VFP grids - then you would be lost and have little value to a VFP shop uses OCX.
>
>The problem is the ease of data binding with VFP - it's cool for grannies cookies - but in the real world it's discrete data and node collections.
>
>Lets say you're moving to NET. The problem is more intense then - you don't have a VFP coursor to complain about reiterative node cycles - you have a recordset to deal with. Better to learn nodes with a DBF before you move to nodes using ADO!
>
>What harm/user confusion can possible come out of that ?
>Your projects will not be competetive with projects that use node addressable controls
>>
>I find navigation/search with smart-grids much faster , key responsive and troublefree - then any treeview implementation.No activeX no ocX - just well equiped VFP grid.
>Like I said - great for granny's cookie recipies - but it would not get you project work at the last VFP shop I visited - and it will not helop you move to NET or DOM or anyother "node" based tool!
>
>In order not to hijack this one, maybe we should start new thread
>about this subject.
>You can high-jack this one - it looks like the comparison is turning into a "who's got the prettiest ugly pig" contest. It ain't going nowhere if that is the case!:-)