Hi Christof,
>
>>1.) VFP could dump the current way it handles windows messages, meaning less code to be maintained by MS and possibly resulting in a smaller run time DLL.
>
>As much as I would like to see this, I would think that it requires almost a rewrite of the kernel of VFP. After all, internally VFP is still a cross-platform tool that probably contains much of the code of FPW 2.6. Changing this to make use of native Windows functions, especially the GDI, means that probably a lot of working code has to be touched. I'd expect at least as many problems as we had with the first release of VFP 3, maybe even more.

Well, as I see it, cross-platform is pretty much of a dead issue so why keep that stuff around. Just more code to maintain that could be eliminated. I do agree, however, about the re-writing the kernel. It wouldn't be the first time, and as you pointed out, might lead to some other, albeit temporary, problems. The question here really is, is it worth it from MS's perspective? I don't know the answer. Given the problems it creates, my gut reaction is to say yes. However, there may be other things that I'm not aware of.

>>This would also mean that certain problems with windows properly being refreshed would disappear.
>
>I really like to see a correctly firing paint event! *s*

Me too.

>>3.) Would provide for better and more reliable interaction with ActiveX controls.
>
>In which way?
>
The example that comes to mind immediately is the MS Coolbar control. In KB article 186123, MS documents that the problems are directly connected to messaging. "The problems occur because Visual FoxPro can not process the messages from these child controls in the Band; therefore, erratic responses occur."

Now it is admittedly an assumption on my part that other ActiveX control from 3rd party vendors aren't similiarly affected. However, I don't think it's a reached by any stretch of the imagination.