>>>>Not necessarily. If the control was designed to be dropped on a form, you're probably not going to be able to CREATEOBJECT it. But if it tries to display anything in a DLL, VFP will block and throw an error.
>>>>
>>>>>Is that also why I can't CREATEOBJECT() the activex control directly?
>>>>>
>>>>>Well that's not quite right. I can createobject() it but nothing on the control works and I get weird 'catastrophic failure' on anything I do.
>>>
>>>
>>>This control doesn't display anything and has no visual elements when instantiated. Is there any way I can verify that this is indeed what's going on?
>>
>>Does it work if you build it into a COM EXE?
>
>Yes. I guess that's my answer :)
>
>Using COM EXE kills my ability to multithread.
>
>Bummer. I really need to speed up this process.

When you instanciate the COM EXE, is it showing any UI? Even popping up something like a splash screen counts as UI. SWAG, maybe there's a .DontShowUI setting for the control (?)

Another option might be to spawn multiple instances of a COM EXE. Since they're separate processes I believe the OS has more options for scheduling them than with a VFP MTDLL. For example, if you have a 4 core CPU maybe you could spawn 4 instances.