>>And, if so, don't you think IT IS a bug that VFP does not have multithreaded >capabilities? :) At least, the same kind of 'bugs' that VFPCOM fixed. But that's all semantics.
>
>No, I don't think this is a bug. It would be a new feature.
>

Sure it would be a new feature, what I was trying to say -with some irony involved- is that the ability to respond to COM events (as the new session class), was a new feature too, not a bug fix.

>
>The UT member is doing it with smoke and mirrors.
Uh? smoke and mirrors? I don't know if you can call it that way, all I know is that it works, and works great. Have you tested it?

Craig, when you move a window it appears to float, but (as you know) what is happening is fast repainting on screen.
When you go to the movies, the characters move, suffer and laugh, but in reality that's only colored light over a screen. What about politics? Marketing?
Life is a play of light,smoke and mirrors.

If I can respond to events raised by Outlook, at the end, it is the same thing if I'm using VFPCOM (smoke and mirrors too because it is not in VFP's libraries?) or VFP7. Sure it is better to have it integrated but the end result is the same.

If I have the ability to efectively process tasks asynchrounuosly it really matters if it is done using an external dll or functions in VFP support libraries?

>Making it work internally may be a different story. I don't know for sure because I don't know C++ or how to make it work or what would need to be changed in the VFP internal code.

Probably it requires a major rewriting, maybe not. Who knows? Can it be done? Of course it can be done.
But let me rewind here, what I'm asking for is a similar kind of solution as Remus provided.
Smoke and mirrors if you like, but an easy, working solution for a first taste of multithreading directly from VFP.
Am I asking for too much?