I'm going to stick to the ActiveX part. Is VFP ActiveX compliant or not. I'm not a Byte head so I can't say whats under the hood. But I've seen and heard a lot of DEV-COM speaker's and people here saying that it is. The problem they say is that the control does not meet the standard. The point I was trying to make is if the above statement is true and if MS decides if you can call it ACTIVEX and sell it to people--- THEN WHY CAN"T THEY MAKE THE PRODUCER MAKE IT WORK WITH VFP.

Of course I understand that you have complete control over this and that is why I'm shouting at you. I feel much better now.... Thanks

OH and have a good weekend........

Jeff

>>The problem IMHO has nothing to do with the seed---It has to do with the ground that our seed is falling on. The VFP Community has beed throwing this seed out by the truck load since VFP. Nothing seems to have popped up yet. Maybe we need more Fertilizer.
>>
>Hi Jeff,
>
>I'm going to stick to Juan's original message regarding the API here in my response. There may be very good reasons for things being the way they are. For example, if the messaging issue is due to VFP using non-standard controls, and to fix it they had to give up the ability to bind the controls to the data, would it be worth it? For a few it might be, but I'd speculate that for most of us, we'd say, "No, no, no! Leave it the way it is." If, to gain pointers, they had to give up the memory management currently in place and it caused a significant performance hit in data manipulation, I think most, if not all of us would say, "Ain't worth it."
>
>Now as far as other issues, we may see some of things we've been asking for in 64 bit VFP. There'll have to be a good deal of re-writing done, so who knows what'll come of it. (I'd still like an independent DE object, but let's not start that again:-)).
>
>Regards,