activex.pp DllGetClassObject problem

[440bx]

Hello,

DllGetClassObject is one of those functions that needs to be implemented by a dll that supports COM.  Because of that there are as many implementations of it as there are dlls that support COM.

It is unusual for an application to call it directly but, if it needs to call it directly, it should use GetProcAddress to get the address of the dll specific implementation it needs to call.  IOW, DllGetClassObject's operation is dll specific.

activex.pp defines DllGetClassObject and it shouldn't because if someone calls DllGetClassObject they'll likely be calling the ole32 implementation instead of the implementation that applies to whatever dll is of interest at the time.

Simply stated, there should not be a way to statically call DllGetClassObject because the call is ambiguous because it is dll specific. 

HTH.

[marcov]

But all those dlls must be registered, and that is what the ole32 version retrieves? It looks up and calls the registered DLL implementation ?

[440bx]

Some of these functions, DllGetClassObject among them are for COM to use.  They are not meant to be used by an app.

Here is, among other things, what the documentation states in DllGetClassObject:

Notes to Callers
You should not call DllGetClassObject directly. When an object is defined in a DLL, CoGetClassObject calls the CoLoadLibrary function to load the DLL, which, in turn, calls DllGetClassObject.

The really critical thing is that, like some other COM related functions, DllGetClassObject is different for every dll that implements it.  Because of this, there should not be a DllGetClassObject exported from any dll since, a dll specific pointer to it must be obtained first to ensure the correct/desired implementation is called.

[PascalDragon]

Delphi's ActiveX unit doesn't provide DllGetClassObject (or DllCanUnloadNow) for what it's worth...