Thanks Ken;

In spite of the gloomy messages that often permeate the UT, I think VFP occupies a pretty good field in the VFP farm. I suspect the VFP team has much more leeway in design goals and product enhancements than some of the other MS teams have (read VB). With the paradigm shift to OOP in VFP 3 I think this was obvious. I think the VFP team proved what can be accomplished when given a great opportunity. VFP isn't constrained by overwhelming success and as developers we are the beneficiaries of the freedom the designers had and, I think, still have.

I truly appreciate how far the product has come since the days of FPD 2.6.

I don't mind if MS thinks of it as a toy because they made it a really good 'toy'. Sometimes the best ideas in the world start out as toys.


>I would re-phrase that and say MT DLLs (multi-threaded DLLs) are useful, but not always the solution. You are right about the server issue. With a non MTDLL, you have FIFO (first in, first out). So if a method is called that takes 5 seconds, and 1 second after it starts the method is called again by another client, the second call will have to wait 4 seconds before it even starts. But using an MTDLL, it would start right away, and execute at the same time. If you have a single processor machine, both process will be mutli-tasked and slow down both, so the first process normally taking 5 seconds might take more than 6 seconds because of the other process running. The solution is hardware, just use a multi-processor machine. This is where the new VFP MTDLLs will really shine. And to clarify, I work in Redmond on the VFP team and I've been working on this upcoming versions (yes, plural) of VFP. Microsoft has been busy on other new stuff for VFP as well, like a very soon to be
>released DLL that allows VFP developers to bind VFP code to COM events.