Using OCX in ALT/COM server..

[AbhiHari]

Hi,

Can anyone let me know if we can use the MSSCript.ocx in a COM server.

When I add the MSSCript.ocx changes in my COM Server code ,my COM server is not registering .

I also tried registering OCX also before registering my COM dll.

Actually the flow is like this--> EXE->DLL->COM DLL->Using OCX

Please help me on this...

Thanks,

[VictorN]

Could this help: http://www.solvusoft.com/en/files/mi.../msscript-ocx/ ?

[AbhiHari]

Could this help: http://www.solvusoft.com/en/files/mi.../msscript-ocx/ ?

Thanks Victor,,,

The link is about issue in Registering MSScript.OCX, I was able to regsiter the OCX properly.

But the issue here is to register the COM DLL which is using OCX

[Igor Vartanov]

But the issue here is to register the COM DLL which is using OCX

You never explained what the registration failure looks like. And what way you made sure the OCX registration succeeded.

Did you debug your activex dll registration at all?

[AbhiHari]

You never explained what the registration failure looks like. And what way you made sure the OCX registration succeeded.

Did you debug your activex dll registration at all?

the command regsvr32 keep on running, seems like it has hung,, Yes OCX I was able to register... No I don't have code to debug the activex dll...

[Igor Vartanov]

the command regsvr32 keep on running, seems like it has hung,,

Now it's time to attach to the process and see where it hangs.

Yes OCX I was able to register...

You were able to see the message. But were you able to run the COM server?

No I don't have code to debug the activex dll...

You have the code of your dll, don't you? So you have the code to debug.

[AbhiHari]

Thanks Igor,,,

I have changed the design, and moved OCX out of COM dll...

[Igor Vartanov]

Thanks Igor,,,

I have changed the design, and moved OCX out of COM dll...

Look, there's nothing bad in using one activex from another activex. Absolutely. Those are just dlls loaded quite a special way. Besides, using COM object creates no dependency that would affect the first (your) activex loading. Moreover, registration of activex does not touch the code more than required for creating proper registry entries, and surely must not depend on other activex species used in the code.

So, the bottom line is: as long as you experience issues with your activex registration, you have no option but debug the activex registration code. Debugging in-proc COM server is identical to debugging regular dll. And no matter what framework your activex is based on (MFC or ATL), the activex can be debugged without any problem.

[AbhiHari]

Look, there's nothing bad in using one activex from another activex. Absolutely. Those are just dlls loaded quite a special way. Besides, using COM object creates no dependency that would affect the first (your) activex loading. Moreover, registration of activex does not touch the code more than required for creating proper registry entries, and surely must not depend on other activex species used in the code.

So, the bottom line is: as long as you experience issues with your activex registration, you have no option but debug the activex registration code. Debugging in-proc COM server is identical to debugging regular dll. And no matter what framework your activex is based on (MFC or ATL), the activex can be debugged without any problem.

Thanks Igor for educating me on this topic...