>I mean with 100,000 people in your RIO demonstration, there'd be 100,000 items in the tree view. The project manager is a treeview and when I argue that we should have more files, people object citing more files and scrolling in the project manager as their complaint.
>RIO is nothing more thana "Hello World" application. When I was learning tree - there was doug hennig - and there was - well there was doug hennig and VB centric white papers at MSDN. The help screens were all VB. We didn't have autocomplete - now we can instanciate from command widow and get an auto-complete listing of the properties.
>
>I had two hopes for RIO - one - that really cool VFP "chicks" would start calling me an inviting me out for cocktales - and the other - to help developers like me jumpstart their OCX skills - I failed in both - it seems:-(
>
>RIO would be great for a contest because it's simple and because it is not much more than a frame work - I gave you the link for a ""real" app - can you inagine how long the NET heads would be working to imitate that.
>
>The contest has to be more than a "prettiest ugly pig" contest. If MS wants me to sell NET - then MS needs to get some "real" net developers - I am sure there are some Java engineers around that have learned NET and could mimic RIO - BUT - I bet the best Java/Net engineer in the world could never mimic RIO's data show when the "hot navigator" is selected - did you click "hot navigator" and see the data flash!

I did, but unfortunately that's about the only good thing in RIO. Kind of a diamond necklace on the pig.

>
>The VFP DLL requirements for treeview (and listviews) "hittest" were (of course) given to the community by Doug Hennig 5 or six years ago -( thanks dh!).
>
>I believe you're saying having a real-time search treeview or something should be 70-80% of our work - sounds like a very central part to me.
>I am saying that industrial applications should not be built around searches - they are unproductive.

Most, if not all, apps need some kind of search.

>
>When I go to home depot, and they need to do a price check on something the people in front of me are buying - it's a crime (or it should be) that I (and the people behind me) should have to wait. They should be able to put that order on hold - like even a phone has a hold button - and do my order.
>
>I go to the web site - usually they scan a bar code from a book - but home depot is UNIX and text - and usually a wand - not a keyboard - is the input device of choice.
>

What has that got to do with what I said? It's when the stupid bar code scanner can't read the stupid tag, that's when everything comes to a halt.

>
>I don't do that. I will not anticipate the user's searches. There are too many combinations - and that's why I don't only use seek.
>I see it in the opposite. I design file systems to maximize speed and user productivity. I anticpate everything (at least as much as I can). I even ask the user. "if you were going to write the program - and arrive at this point in a process - how would you design it to behave."
>
>Sometimes I show up with a search control as simple as a combo box - and they user wants a simpler solution - like a text box!

I anticipated that the user does want some kind of search utility. I give them one so they can be productive and they don't have to call me up to add new searches and be unproductive while waiting. They control what they can search for. I therefore don't have to try and cram all kinds of textboxes and combos into some cobbled-up search utility, which gets uglier the more things the user asks for.

>
>There's no way I can build all the indexes for all the different possible sort orders.
>Yes you could - you just need to beleive you can!
>

Let's say I have 5 fields in my table. ID, FirstName, LastName, AddressFK

The possible combinations of searches and ordering are already too numerous to justify building indexes for all of these fields. Worse yet, I can't even put the data in order by AddressFK, 'cause the user doesn't want that. They probably want it ordered by city. If I do add all the indexes, saving a record will be slower. That's not even a real-world example and it already fails.

>Unfortunately, in this case I believe it's your baby, you fix it. You should have an excellent VFP demo before you demand a competition.
>It's a hello world app I slammed together in four hours for an article - it's not anything more than that.

Then stop trying to tell people they have to duplicate it. It's not worth anybody's trouble.