>VFP will not take advantage of multiple processors. The OS will. I stand by my statement.

I really am interested, then, in your take on the thread: A tip on hardware to speed up VFP Thread #472486 Message #472486

I note that you were not a participant in it back then.



>
>
>>
>>Craig, slip into your asbestos pants... your answer is fatuous!
>>
>>Last year I rewrote a significant portion of a User interface to optimize it for Terminal Services.
>>
>>Briefly, the original implementation built a flat file, from many tables, that was then used as the source for a tree view control. For states with small numbers of items (a few hundred) this strategy was fine. But some states had thousands of items and it was taking up to a minute to build the flat file with the CPU running at 100%. This adversely affected all other TS Users on the same server.
>>
>>By changing to dynamic expansion of the tree nodes, and switching wherever possible to arrays instead of cursors (to reduce file handle usage), I was able to get the system back to near instantaneous responses with very low CPU usage.
>>
>>Close analysis also reveals that the OS was doing a poor job of caching material retrieved from disk. One would have anticipated that after the first User (on a particular server) had started the system, that file content would be cached, and subsequent Users would see a faster application start. This was not the case.
>>
>>Other developers I work with, have noted that displaying complex images, say a bitmap or JPG assigned to _Screen.Picture, can have a major impact on getting the screen, and changes to it (say moving a form) across the wire (especially if it is a remote dial-up session) – one needs to bear in mind that it is not the highly compressed JPG that is transferred, but rather the decompressed version sitting in Video RAM.
>>
>>So to sum up, you are talking out your butt. There are many issues involved – and in general VFP is well suited to deployment on a multi processor Terminal Server, if some basic rules are adhered to.