Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Importing a DLL from a class

Importing a DLL from a class

Scheduled Pinned Locked Moved C / C++ / MFC
c++help
5 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • F Offline
    F Offline
    feederman
    wrote on last edited by
    #1

    Hi guys. I am trying to import/link the MSXML.Dll from a class i have created in C++. Defined in the classes header file is a datamember of type IXMLDOMDocumentPtr. Certain functions in the class then use objects and functions in the MSXML.dll. My code works fine if i "#define import 'dllPath'" in the header file. Problem is on a client machine i may not know the full path to the DLL. I need a way of dynamically loadind the DLL so my class can access all its fucntions and objects. I have tried using LoadLibary() but am not sure how it should be used to import a DLL into a class. The call to LoadLibary() has to be placed in the .cpp file and then i get errors form m y header file as IXMLDOMDocumentPtr cannot be found. Sorry 4 the essay, hope someone can help. Cheers Simon Turner

    B 1 Reply Last reply
    0
    • F feederman

      Hi guys. I am trying to import/link the MSXML.Dll from a class i have created in C++. Defined in the classes header file is a datamember of type IXMLDOMDocumentPtr. Certain functions in the class then use objects and functions in the MSXML.dll. My code works fine if i "#define import 'dllPath'" in the header file. Problem is on a client machine i may not know the full path to the DLL. I need a way of dynamically loadind the DLL so my class can access all its fucntions and objects. I have tried using LoadLibary() but am not sure how it should be used to import a DLL into a class. The call to LoadLibary() has to be placed in the .cpp file and then i get errors form m y header file as IXMLDOMDocumentPtr cannot be found. Sorry 4 the essay, hope someone can help. Cheers Simon Turner

      B Offline
      B Offline
      Brad Sokol
      wrote on last edited by
      #2

      Becase MSXML.dll implements a bunch of COM objects, you don't need to do an explicit LoadLibrary call. COM takes care of this for you when you CreateInstance a new instance of a coclass. You only need to know the class id or progid. COM looks up the rest in the registry. That said, you obviously need to have the correct version of the MS XML parser installed on the client machine. Different COM class names map to different versions of the DLL. Brad

      F 1 Reply Last reply
      0
      • B Brad Sokol

        Becase MSXML.dll implements a bunch of COM objects, you don't need to do an explicit LoadLibrary call. COM takes care of this for you when you CreateInstance a new instance of a coclass. You only need to know the class id or progid. COM looks up the rest in the registry. That said, you obviously need to have the correct version of the MS XML parser installed on the client machine. Different COM class names map to different versions of the DLL. Brad

        F Offline
        F Offline
        feederman
        wrote on last edited by
        #3

        I did realise about the different versions of the msxml.dll parser. That is why i was planing to pack the msxml.dll version 1,0 into my installer (as its the smallest in size)and then just put it somewhere on client machine. I could then import it via #define import"", but the path may vary unless i just put the DLL in C:/. That is why i wanted to laod it dynamically in code so i coudl use the regitry to find the path to the DLL.

        B 1 Reply Last reply
        0
        • F feederman

          I did realise about the different versions of the msxml.dll parser. That is why i was planing to pack the msxml.dll version 1,0 into my installer (as its the smallest in size)and then just put it somewhere on client machine. I could then import it via #define import"", but the path may vary unless i just put the DLL in C:/. That is why i wanted to laod it dynamically in code so i coudl use the regitry to find the path to the DLL.

          B Offline
          B Offline
          Brad Sokol
          wrote on last edited by
          #4

          Hmm...I think you may be a bit confused on how to program with COM ojbects and how they're used at run-time. #import is used only at compile time to include declarations of objects supported by the COM DLL. The path is only relevant on the computer where your code is being compiled. This is very similar to #include. At install time, you must register any COM components that you install. This adds entries to the registry that the COM APIs use to find the DLLs and create the proper execution environment for the components. Most COM DLLs export a function called DllRegisterServer which the DLL author must provide to perform the necessary registration steps. Most installer packages (InstallShield, Wise, etc.) will call this function if you specify the DLL as requiring registration. You can also register a component using the regsvr32.exe utility, which calls DllRegisterServer. So, the path to the DLL is established at registration time and stored in the registry. You can install the DLL anywhere. At run time, you instantiate an instance of a coclass by specifying either a CLSID or PROGID. The COM API CoCreateInstance (which is either called by the smart pointer, or by your code directly, depending on how you've written things), performs a lookup in the registry to find the location of the DLL. A warning about installing MSXML yourself. With later versions of the parser, there are more than one DLL. I'm not sure about V1.0. You are probably better off finding out what installation method Microsoft recommendeds. They probably have an installation package that you can re-distribute. That installer will install all required components and perform the necessary registration. Secondly, V1.0 is very old. Newer versions support more of the XML and related standards. Finally, depending on what OS you're targetting, a version of the parser may already be installed. HTH Brad

          F 1 Reply Last reply
          0
          • B Brad Sokol

            Hmm...I think you may be a bit confused on how to program with COM ojbects and how they're used at run-time. #import is used only at compile time to include declarations of objects supported by the COM DLL. The path is only relevant on the computer where your code is being compiled. This is very similar to #include. At install time, you must register any COM components that you install. This adds entries to the registry that the COM APIs use to find the DLLs and create the proper execution environment for the components. Most COM DLLs export a function called DllRegisterServer which the DLL author must provide to perform the necessary registration steps. Most installer packages (InstallShield, Wise, etc.) will call this function if you specify the DLL as requiring registration. You can also register a component using the regsvr32.exe utility, which calls DllRegisterServer. So, the path to the DLL is established at registration time and stored in the registry. You can install the DLL anywhere. At run time, you instantiate an instance of a coclass by specifying either a CLSID or PROGID. The COM API CoCreateInstance (which is either called by the smart pointer, or by your code directly, depending on how you've written things), performs a lookup in the registry to find the location of the DLL. A warning about installing MSXML yourself. With later versions of the parser, there are more than one DLL. I'm not sure about V1.0. You are probably better off finding out what installation method Microsoft recommendeds. They probably have an installation package that you can re-distribute. That installer will install all required components and perform the necessary registration. Secondly, V1.0 is very old. Newer versions support more of the XML and related standards. Finally, depending on what OS you're targetting, a version of the parser may already be installed. HTH Brad

            F Offline
            F Offline
            feederman
            wrote on last edited by
            #5

            Thanks for your help mate. Cheers

            1 Reply Last reply
            0
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            • Login

            • Don't have an account? Register

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • World
            • Users
            • Groups