What causes COM to change?

[Paul MacFarlane]

I have a PB9-DLL I use to call a COM object.
On all machines, a small PB9 EXE works fine.

But, on some machines, a NON-PB EXE, the DLL won't create the COM object.

What outside, affects the ability of the PB-DLL to create an instance of the COM object?
I can't find how I can get any error info either to tell me more...

Suggestions?

Thanks,

[Steven Pringels 3]

tips...

Hi Paul,

1. Check if the COM Dll is registered, that is pretty obvious (use Regsvr32 to
register).
2. Use Dependency Walker (freeware tool) to see if all the components are present.

Maybe other people here can add some more tips but these are the ones that come to mind in pica-second.

[José Roca]

DLLs need to initialize the COM library with CoInitialize or CoInitializeEx and uninitialize it with CoUninitialize. The problem is that DLL_PROCESS_ATTACH is not a reliable place to do it, so you will need to write an exported function or procedure for it, e.g.

SUB MyInitialize ALIAS "MyInitialize" () EXPORT
   CoInitialize BYVAL %NULL
END SUB

SUB MyUninitialize ALIAS "MyUninitialize" () EXPORT
   CoUninitialize
END SUB

I'm assuming that you are talking of a standard DLL, not a COM server.

[John Petty]

Interesting comment Jose, would it help if the DLL is explicately loaded by the non PB exe a little later in the program. As those functions are part of the PB run time then the PB exe will also be executing them. If the DLL is loaded by the non-PB exe later in its start up via an explicit load rather than automatically does it have a better chance of success?

[José Roca]

No. The COM library is not initialized globally. What you can try is to call CoInitialize at the very start of the non-PB EXE program that uses the PB DLL, and CoUninitialize at the very end. Not sure if it will work, however. I only use the PB compilers with Windows.

[Paul MacFarlane]

Thanks Guys....

I'm a little confused though about calling CoInitialize, etc. My DLL is NOT a COM server, it just happens to use COM components....

I am not using any code in DLL_PROCESS_ATTACH - I don't even have one.

So, what is confusing to me is what the PB.EXE does when it loads the PB.DLL versus what a NON-PB-EXE does (or doesn't do).

Under certain conditions the NON-PB-EXE uses the PB-DLL fine. But I can't determine what those conditions are - so I can correct them.

So, the PB-EXE calls the PB-DLL fine all the time.
The NON-PB-EXE calls the PB-DLL fine SOME of the time.

Actually, the call works fine, it's just that the function in the DLL instantiates a COM object and that is unsuccessful in the NON-PB-EXE sometimes.

[José Roca]

My DLL is NOT a COM server, it just happens to use COM components....

But it can't use COM realiabily if the COM library has not been initialized.

So, what is confusing to me is what the PB.EXE does when it loads the PB.DLL versus what a NON-PB-EXE does (or doesn't do).

PB calls CoInitialize at the beginning of PBMAIN and CoUninitialize at the end. This is why I'm suggesting that you try to call CoInitialize at the very start of the non-PB EXE program that uses the PB DLL, and CoUninitialize at the very end.

[Paul MacFarlane]

Thanks Jose...

I'm starting to understand a little better now....

So, if I understand, a PB-EXE calls CoInitialize/CoUninitialize regardless of whether it's using COM or not (as in this case because the COM is hidden in a DLL).

So, can I just add CoInitialize/CoUninitialize calls to my DLL function so I don't have to burden another developer with that step?

I understand you said it's not reliable to do that in DLL_PROCESS_ATTACH.

This DLL contains individual unrelated calls. So, unless it's bad to call CoInitialize/CoUninitialize multiple times, maybe that is my best solution.?

Also, where do I find more info on CoInitialize/CoUninitialize. I don't see it....


Thanks again for your help and insight - and education....

[Paul MacFarlane]

Okay Jose....

I found the calls to CoInitialise, etc... and it worked !

Now, the only remaining question is: Is it bad to call it in pairs within the functions themselves...

In other words, do I need to put the requirement on users of the DLL to call CoInitialise/CoUnInitialise or is there a way I can do it for them?

Thanks again,
Paul

[José Roca]

Just try it. I never have done it this way, so I can't confirm or deny it with certainty.

[Paul MacFarlane]

I'm trying it and it seems to work fine...

I'll let you know if I get some weird results somehow....

Thanks again,
Paul