Registering COM Libraries

[Thomas Udo Eichler]

Hello friends,

I am about to perform a change to use a Domino Cluster monitoring Tool. That tool uses "Domino Automation Class x.x" as registered COM library. Unfortunately this library does not belong to the Domino server but to the Notes client. On the system I want to implement my tool no Notes client is installed. The file "domobj.tlb" is available but not registered because the registration is done while a Notes client is was installed. As we do not want to put the whole client on the Domino server, how can I manage to register this particulat tlb file to be able to use its com objects?

Many thanks in advance,

Thomas

[Edwin Knoppert]

1) Afaik you can open the tlb with the combrowser without registering the ocx.

2) How safe is it to use a com object without a full install, won't the ocx call other libraries?

[Thomas Udo Eichler]

Com Browser does not work this way

Hi Edwin,

first I tried to open the tlb with the build in COM Browser but A) it always complains about the lib not registered
B) As this is the only tlb file registered for Notes in a fully installed environment I am pretty confident that it would be sufficient.

Thanks for your reply

Thomas

[Fred Harris]

If the COM object isn't registered, Windows COM services (various system components) won't be able to load the library, for ultimately what happens behind the scenes is that COM services somewhere does a LoadLibrary() call that will fail if the object isn't registered. So in a client that checks return values it will be able to determine that the object wasn't created. Here is an example of a DllRegisterServer() in C++ from one of my projects. Its possible to see where the type library itself is registered with COM (it'll show up in the registry), and where the component is registered with RegisterServer().

HRESULT __stdcall DllRegisterServer()
{
 char DllPath[256];
 OLECHAR wDllPath[256];
 ITypeLib* pTypeLib;

 GetCurrentDirectory(256,DllPath);
 strcat(DllPath,"\\Component.tlb");
 mbstowcs(wDllPath, DllPath, 256);
 HRESULT hr=LoadTypeLibEx(wDllPath, REGKIND_REGISTER, &pTypeLib);
 if(FAILED(hr))
 {
    printf("LoadTypeLibEx() Failed!\n");
    return hr;
 }
 else
    printf("LoadTypeLibEx() Succeeded!\n");
 pTypeLib->Release();
 
 return RegisterServer("component.dll",CLSID_InsideDCOM,LIBID_Component,"Inside DCOM Sample","Component.InsideDCOM","Component.InsideDCOM.1",NULL);
}

If there's no RegisterServer() and the component isn't registered, there won't be any GUID or CLSID in the registry holding a path to where the *.ocx file lives. The registration of the component in the Windows registry is more fundamental than the registration of the type library, I believe. While I've never tried it, I see no reason why LoadTypeLibEx() couldn't be called to successfully load a type library in the registry, but then NOT register the component. In that case you would have a type library, but no usable component. In fact, that is actually the case in the above procedure before RegisterServer() is called in the return.

[Thomas Udo Eichler]

Just registering it ?

Hi Fred,

could it be possible to just export/import the keys from registry where "domobj.tlb" was mentioned ?

Best regards,

Thomas

[Edwin Knoppert]

I don't think we should focus on how to circumvent the tlb issue.
Use a virtual pc or client's pc to obtain the information.

At the end, PB can load the ocx *without* being registered but you'll need the interface definition.
Unless it's a dual interface and you find using late bound calls sufficient.

[José Roca]

At the end, PB can load the ocx *without* being registered but you'll need the interface definition.

With the new compilers, but I have asked to Thomas which compiler he is using and he is using PBCC 4.

[Edwin Knoppert]

Oh, anyway PB provided the code somewhere on this board.
Maybe it is useful then.