>>>I agree, the fox database engine with dbfs is extremely fast. It would be cool if the database engine was available in other langauges much like the Access database engine is available to C++, Visual Basic. :->
>>
>>
>>Wouldn't that be great!
>>
>>Another extraordinarily powerful component of VFP that is often overlooked is it's macro substitution facility. You can literally write code that writes code, execute it on the fly, all within a distributed app. For *database* applications, this is super because generally you are passing a complex command to VFP's engine (thus, fast execution by the DB and GUI engines once the command processor has completed its part). However, as noted before, this aspect of VFP is equally frustrating (on the slow side) when you try to use numerically intensive algorithms in your app because VFP is an interpreted language.
>>.
>
>Hmmm...macro substitution....Peter, can you do this in C++?
>
>Also, multi-threads...no...but because Windows in multi-tasking, simple multi-threading can be simulated.
>
>Joe

A well designed C++ app has no need for macros. In C++ you have features such as pointers to functions that eliminate the need for this. The main reason I'm interested in writing a multi-threaded app is to increase the perceived responsiveness of the app. So basically, I would separate the user interface from the data processing thread at the minimum. I could then increase the thread count where needed to increase responsiveness to the user. Right now this becomes very useful in situations where I might have a two panel window with parent/child grids using sql views. If you move the pointer in the parent grid, the app has to requery the child view. As soon as the requery begins the user is held hostage to the app until completion. Wouldn't it be nice to let the user move the rec pos after the requery has begun and then to cancel the requery and start again? While this doesn't increase the efficiency of the app, it increases the implied efficiency...

Peter