visual c++ - How do I use a COM DLL with LoadLibrary in C++ -


First of all, COM is like black magic for me, but I have to use Com DLL in a project which I I am doing

Therefore, I have a DLL that I am developing and I need some functionalities that are available in a separate COM DLL. When I look at the COM DLL with Depends.exe, I see DllGetClassObject () and other functions, but I do not see any difference.

I have a COM DLL source code, but this is a mess and I want to use the COM DLL in the binaries such as a big black box that does not know what's going on inside. .

So, how can I call the COM DLL function from my code using LoadLibrary? Is this possible? If, yes, can you give me an example of how this can be done?

I am using Visual Studio 6 for this project.

Thanks a lot!

Typically you use CoCreateInstance () to instantiate objects from a COM DLL < Code> will use. When you do this, there is no need to first load the DLL and obtain the proc address as you would have to do with a normal DLL. The reason for this is that Windows "knows" how a CNLL is implemented, which is implemented in DLL, and how to instantiate it (let's assume that the COM DLL is registered, which Usually)

Suppose you have an ID DLL with the IDog interface you want to use. In that case,

dog.idl 
  interface ID: IUnknown {HRESULT bark (); }; Cockle's Dog {[Default] Interface IDG; };

myCode.cpp 

  idog * piDog = 0; CoCreateInstance (CLSID_DOG, 0, CLSCTX_INPROC_SERVER, IID_IDOG, and piDog); // windows trigger the idag object and put the pointer in the pygodic PDF-> bark (); // do stuff piDog- & gt; Release (); // it was done now piDog = 0; // There is no need to remove it - COM objects usually delete themselves

All of these memory management content can be quite confusing, however, and ATL provides Smart Pointers which can be immediately Works for work; Making these objects a little easier: 

  CCMPT & lt; IDG & gt; dog; Dog.CoCreateInstance (CLSID_DOG); Dogs & gt; Bark ();

Edit:

When I said above:

Windows "knows" types of implementing a COM DLL About [.. and] what DLLs are implementing in it

... actually glossed on how Windows really knows it, it does not have magic, though it is not the first time Mystery can be ignorant.

COM library types come with libraries, which gives a list of interfaces and collocals provided by the library. This type library is in the form of a file on your hard drive - often it is directly embedded in the library as a DLL or XE. Windows knows where to look for the Type Library and Com Library in the Windows Registry. Entries in the registry tell Windows that where the DLL is located on the hard drive.

When you call CoCreateInstance , Windows sees the clsid in the Windows registry, finds the corresponding DLL, loads it, and calls the appropriate code in the DLL Executes the COM object that executes.

How does this information come into the Windows registry? When a COM DLL is installed, it is registered, it is usually done by running, which in turn loads your DLL into memory and calls a function called DllRegisterServer . This function, implemented in your COM server, adds Nissanar information to the registry. If you are using ATL or any other com framework, then it is probably being done under the hood so that you do not have to interact directly with the registry. DllRegisterServer is required to call only once, at installation time.

If you try to call CoCreateInstance for a COM object that is not registered yet, regsvr32 / DllRegisterServer process, then CoCreateInstance will fail with an error that says:

class not registered

regsvr32 on your com server, and then try again.


Comments

Post a Comment