>>This is where you lose me - why is it a "good thing". How do you know how it will perform on something that isn't in existence yet ?
>
>Well, lets use my current app as an example. The previous version was all in FPD ad FPW. Alot of the browse screens are instantanious. In the new version, we use grids, and we also can remember grid and form settings per user (the position and width of columns, ect.). Because of that, among other things, on current hardware each for takes between one second and three seconds to load.
>
>We don't think of that delay as a bad thing, because we're pretty sure that over the next couple of years, the hardware will speed up the process of loading the grid columns, and the software will perform well, with the same rich features it always had.
>
>While it may be pokey in its current state, its not unsuitable and very usable.
>
>So, we think of it as a good thing, we have the right amount of features with acceptable performance that will only be getting better.

Mike;

I remember using Codebook 3.0 shortly after VFP 3.0 was released. If we had 450 mhz CPU’s then, Codebook may have been very popular. As it was it had great promise but even with the fastest machines available at that time (100 mhz CPU’s) clients would not accept it. Add the DBCX and as we would say, “Wait for the entire world to instantiate before anything would happen”! We are talking about 15 to 30 seconds to open a form.

Seems like most users do not worry if it takes 1.5 seconds to open a form. That is my target maximum. Clients accustomed to slow machines do not seem to mind waiting a little longer for something to happen.

Intel announced two weeks ago it is working on a 20 Ghz CPU. No release date – perhaps they are trying to “keep AMD” on their toes.

Tom