using ATL DLL in non-ATL way
-
Sorry that the subject is vague because it's hard to describe my question in one line. I have zero experience with ATL. I was given this ATL DLL project at work that embeds web browser on our application. I was using #import [browser.dll] to access the methods, and CreateInstance() to create the browser. That's how it was used in the example exe project that used that DLL. My lead suggested that I should remove #import due to its hard-coded path dependency, and I should just link it using the lib file that DLL generates during compilation. The DLL is guaranteed to reside in the same directory as the main exe, and it'll not be replaced by any other DLL. What's the best way to fix this problem? But I noticed that lib files don't generated when you compile ATL DLLs (I could be wrong). Can somebody lead me to an example? Thanks in advance.
-
Sorry that the subject is vague because it's hard to describe my question in one line. I have zero experience with ATL. I was given this ATL DLL project at work that embeds web browser on our application. I was using #import [browser.dll] to access the methods, and CreateInstance() to create the browser. That's how it was used in the example exe project that used that DLL. My lead suggested that I should remove #import due to its hard-coded path dependency, and I should just link it using the lib file that DLL generates during compilation. The DLL is guaranteed to reside in the same directory as the main exe, and it'll not be replaced by any other DLL. What's the best way to fix this problem? But I noticed that lib files don't generated when you compile ATL DLLs (I could be wrong). Can somebody lead me to an example? Thanks in advance.
I should add that I could modify this ATL DLL source anyway I want. It just has to work.
-
Sorry that the subject is vague because it's hard to describe my question in one line. I have zero experience with ATL. I was given this ATL DLL project at work that embeds web browser on our application. I was using #import [browser.dll] to access the methods, and CreateInstance() to create the browser. That's how it was used in the example exe project that used that DLL. My lead suggested that I should remove #import due to its hard-coded path dependency, and I should just link it using the lib file that DLL generates during compilation. The DLL is guaranteed to reside in the same directory as the main exe, and it'll not be replaced by any other DLL. What's the best way to fix this problem? But I noticed that lib files don't generated when you compile ATL DLLs (I could be wrong). Can somebody lead me to an example? Thanks in advance.
MonkuMonku wrote:
My lead suggested that I should remove #import due to its hard-coded path dependency, and I should just link it using the lib file that DLL generates during compilation.
#importhas nothing to do with linking.#importgenerates wrapper classes for COM objects at compile time. COM operates completely at runtime and does not use LIBs to find DLLs.--Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ Dunder-Mifflin, this is Pam.
-
MonkuMonku wrote:
My lead suggested that I should remove #import due to its hard-coded path dependency, and I should just link it using the lib file that DLL generates during compilation.
#importhas nothing to do with linking.#importgenerates wrapper classes for COM objects at compile time. COM operates completely at runtime and does not use LIBs to find DLLs.--Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ Dunder-Mifflin, this is Pam.
-
As suggested by Michael, the #import generate the wrapper classs for coclasses that are part of ATL dll, any COM DLL need to be registered before it use, and location of dll is irrelevent as it shourld be registed in the windows registry by using "regsvr32" command. if you don't want to use the #import you can directly create the instance of class by using CoCreateInstance but life is more tough without #import as you have to handle the AddRef and Release part of your own. Regards, Sunil Tonger
-
As suggested by Michael, the #import generate the wrapper classs for coclasses that are part of ATL dll, any COM DLL need to be registered before it use, and location of dll is irrelevent as it shourld be registed in the windows registry by using "regsvr32" command. if you don't want to use the #import you can directly create the instance of class by using CoCreateInstance but life is more tough without #import as you have to handle the AddRef and Release part of your own. Regards, Sunil Tonger