Peter,

When you take into account today's processor speeds, rampamt RAM (pun attempted), fast video drivers, much faster hard drives, etc then the screen bits really has negligible impact. Sure DOS's 2080 characters will be fastest of all, but you should hardly see the difference anymore.

JAVA (or anything else) all operates on the same hardware.

There are a few possibilities for factors at work here:

1) VFP development is focussed on mid-tier where visible speed is not a problem.
The corollary to this is that the VFP team is neglecting the GUI aspects. Since we are constantly told that they are a lean but mean team, this has a real possiblity of being true.

2) Again relating to mid-tier, this time regarding speed generally... VFP obviously is intended to be a front-end to *SOMETHING ELSE*, be it SQL Server or Oracle or whatever, where actual speed is largely determined by the performance of *those* components rather than purely VFP's. So the VFP team might be working real hard to make *THAT* VFP code as tight and fast as possible, but again (small team) at the expense of other things, even including native VFP table access.

3) The recent FPA article "Rushmore queries: Less is More" leads to some interesting possibilities too, mainly because this 'problem' has arise quite suddenly. I really have to wonder WHY that is the case. Yes, I know that the article states that the same behaviour was observed in FPD and FPW, but there is still something a little fishy about it. The article did not state whether or not the FPD/FPW runs were performed on a system with VFP also installed on it. I would like to see like tests run on a system known to have had *only* a virgin (from diskette) FPD and FPW installation and with VFP definitely never having seen that particular machine.

Where speed was always an issue, maybe it is less so now? - who knows.

One thing is for sure, and that is that visions of character mode screens really have no real future for the general case.

There is, in my opinion, one sure-fire way for MS to have VFP just fade away into the sunset, and that is to stop delivering enhanced GUI functionality *and* neglect speed issues generally. This would juust about guarantee attrition *from* VFP and to any other product which has some nice fancy GUI stuff and adequate speed.

Cheers,

Jim N


>>What has happened? has the attraction of a GUI environment corrupted us all ?
>>Compare your results to a (GOD forbid!) DOS or UNIX based system running an earlier version of FoxPro, any differences?.
>>
>>It's time to say BUGGER the work arounds, BUGGER the wait, our clients expect it to be right, first time not third or fourth release, what do WE expect from the supplier of our software??????????
>
>I hate the fact that the my apps are slower than the ones they replace.
>
>The DOS environment had 2080 characters on the screen to be manipulated. A 800x600 Windows screen has 480,000 bits to be manipulated. That accounts for a lot of the difference but certainly not all.
>
>I guess no one wants to go back to character mapped screens but I really think speed matters. Lets keep pushing for faster system code. I'm willing to learn Java is that would solve the problem.
>
>Peter