Hi Colin,

<< I'm not making exuses for VFP. I'm just restating what I have read here and other places and was under the impression that this statement came from M$. Not that this makes it gospel and the statement could be wrong but I haven't heard anything *factual* to dispell this. >>

The statement is true and I've heard it from M$ direct myself. The problem is that as Jim Nelson so elegantly put it, "It's a load of crap" and clients could care a less about it. The problem is that it comes off as VFP is better because ActiveX controls don't work. I don't know the reasoning behind why the Fox team chose to have such strict enforcement, maybe because they didn't want ActiveX controls to create problems with VFP's memory management, but actually I think the cause is much deeper. Here's my theory on the cause of many of the underyling problems with VFP.

FPW 2.6 and VFP 3.0 both by passed the OS and handled writing to the screen directly, the Fox team wrote all of the routines to write to the screen with few, if any OS calls, so they could use the same code on the Mac and in Windows. I think this is why VFP's GUI controls are sluggish when compared to those of other development environments. I also think that when you drop an ActiveX control into a VFP form there's potential for problem because the control isn't hosted by a standard windows form. I think this is why certain controls that work fine when dropped into a VB form give you errors like "Object Class is Invalid for this Container" or something like that. It seems that 5.0 still has a lot of the same screen writing code as 3.0 and so the problems continue. I don't know if that has changed in Tahoe or not.