Kevin,

>Agree on this one. Anyway, I designed a grid class that does index/order stuff transparently. After temporary index is created, Subsequent reordering is instantaneous, no matter how many rows the result set has.

>Well, personally, I agree, because I've done this as well - wrote something generic in a VFP grid to automatically create a tag on every column. This is a good example of writing something generic as a functional equivalent of another tool's capabilities, and I'm fine with that.

>However, when I've mentioned in the past that I've written some generic equivalents in .NET (like a generic LOCATE and other functions), the responses have always been along the lines of "it's going to be slower", "you're introducing more code, and it's not likely to be standard, it increases the risk of bugs".

>While I don't regard those responses as completely without merit, in the context they were basically "knee-jerk" reactions. Why is it considered acceptable to write a good functional equivalent in one tool, but not in another tool? (I'm not asking you specifically).

I still stand by statements as you refered to above. And if .NET grids can sort their contents without a single line of code that definately is better than when you have to do yourself. The VFP coding is very simple and straigthforward, but even here there are problems (you'll have to use CDX if that underlying table is going to be part of an transaction, and by default the sorting does not work on the selected record, but on the top record). So, yes the sorting of a .NET grid is better than the clumsy way that you have to do in VFP, esspecially from a newbee standpoint of view. But both methodologies are thightly related with the actual implementation of data handling and are hard (and unlikely) to change. For VFP programmers INDEXES and SET ORDER are the preferred method of sorting data for a variaty of reasons.

Walter,