>>I'm not sure, but I think you are talking about Crescest / Progressive ?
>>I have had several contacts with them re: MSComm32 / PDQcomm. Some information from them, and some others, indicate that there are some standards issues that have not been resolved with OCX (Active-X).
>>One of these has to do with *self registration*, which appears to be required by FoxPro. VB on the other hand does not *Require* self registration. Crescent stated in an e-mail to me that their controls are tested under VB, and *should probably* work in FoxPro, but that it could not be counted on. Also, if they did not work under FoxPro, then their technical support could not address this, although the control could be returned for credit.
>
>I still don't understand why other OCXs are working with Visual FoxPro and Crescent think theirs won't. Anyway, it is working. Like I said, I am able to put the control on my form. But, whenever I open the form again, I have a custom message saying that it is only for VBs. There's no reason to lock the control just for VB. I never seen that for another control.

I don't understand the difference myself ! I do know that the mscomm32.ocx supplied with VB also includes a .oca file. I have been told that this is the separated registration information. Until the registration info is combined, FoxPro will allow the control to be placed on a form, but may not allow development, or may fail upon attempt to register during distribution. A co-worker said he saw an article about how M$ is working hard attempting to resolve OCX standards issues. I don't know how much of any of this information is reliable, but there does seem to be some unresolved problems, and Crescent may be trying to prevent difficulty by limiting the OCX to VB.