What are the ways a COM dll can be used? + questions
-
* Just by knowing the component's CLSID & the interface's IDs? Use a component with the "import" directive, that takes information from the .tlb file? <-won't this require any header file? * Creation using ProgIDs is efficient? Please verify: * A COM DLL doesn't mean a component. A COM dll may contain any number of components inside. (that we do by adding simple ATL object into workspace?)//Containment ,aggregation etc. * A CoClass is a component object. As a COM DLL can contain more components, there'll be more CoClasses accordingly.
-
* Just by knowing the component's CLSID & the interface's IDs? Use a component with the "import" directive, that takes information from the .tlb file? <-won't this require any header file? * Creation using ProgIDs is efficient? Please verify: * A COM DLL doesn't mean a component. A COM dll may contain any number of components inside. (that we do by adding simple ATL object into workspace?)//Containment ,aggregation etc. * A CoClass is a component object. As a COM DLL can contain more components, there'll be more CoClasses accordingly.
grassrootkit wrote:
* Just by knowing the component's CLSID & the interface's IDs? Use a component with the "import" directive, that takes information from the .tlb file? <-won't this require any header file?
A header file will be created during the build process that usually has the .tlh extension.
grassrootkit wrote:
* Creation using ProgIDs is efficient?
In comparison to what? The CLSID I presume. Due to how the registry is organized, using the ProgID will require an extra round-trip to find out the CLSID since it's underneath that key in the registry the path to the dll is found.
grassrootkit wrote:
* A COM DLL doesn't mean a component. A COM dll may contain any number of components inside.
Correct in the sense that a COM DLL may contain more than one COM server.
grassrootkit wrote:
* A CoClass is a component object. As a COM DLL can contain more components, there'll be more CoClasses accordingly.
Yes.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
* Just by knowing the component's CLSID & the interface's IDs? Use a component with the "import" directive, that takes information from the .tlb file? <-won't this require any header file? * Creation using ProgIDs is efficient? Please verify: * A COM DLL doesn't mean a component. A COM dll may contain any number of components inside. (that we do by adding simple ATL object into workspace?)//Containment ,aggregation etc. * A CoClass is a component object. As a COM DLL can contain more components, there'll be more CoClasses accordingly.
- Just by knowing the component's CLSID & the interface's IDs? Use a component with the "import" directive, that takes information from the .tlb file? <-won't this require any header file? the #import creates .tli and .tlh files which are headers - Creation using ProgIDs is efficient? it must be slower because it looks at the progid in registry then at the clsid - A COM DLL doesn't mean a component. A COM dll may contain any number of components inside. (that we do by adding simple ATL object into workspace?)//Containment ,aggregation etc. yes a COM DLL can have many components inside - A CoClass is a component object. As a COM DLL can contain more components, there'll be more CoClasses accordingly. yes with ATL you have no problem, each class factory is instanciated within an OBJET MAP
-
grassrootkit wrote:
* Just by knowing the component's CLSID & the interface's IDs? Use a component with the "import" directive, that takes information from the .tlb file? <-won't this require any header file?
A header file will be created during the build process that usually has the .tlh extension.
grassrootkit wrote:
* Creation using ProgIDs is efficient?
In comparison to what? The CLSID I presume. Due to how the registry is organized, using the ProgID will require an extra round-trip to find out the CLSID since it's underneath that key in the registry the path to the dll is found.
grassrootkit wrote:
* A COM DLL doesn't mean a component. A COM dll may contain any number of components inside.
Correct in the sense that a COM DLL may contain more than one COM server.
grassrootkit wrote:
* A CoClass is a component object. As a COM DLL can contain more components, there'll be more CoClasses accordingly.
Yes.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownhopefully we gave the same results ;)
-
grassrootkit wrote:
* Just by knowing the component's CLSID & the interface's IDs? Use a component with the "import" directive, that takes information from the .tlb file? <-won't this require any header file?
A header file will be created during the build process that usually has the .tlh extension.
grassrootkit wrote:
* Creation using ProgIDs is efficient?
In comparison to what? The CLSID I presume. Due to how the registry is organized, using the ProgID will require an extra round-trip to find out the CLSID since it's underneath that key in the registry the path to the dll is found.
grassrootkit wrote:
* A COM DLL doesn't mean a component. A COM dll may contain any number of components inside.
Correct in the sense that a COM DLL may contain more than one COM server.
grassrootkit wrote:
* A CoClass is a component object. As a COM DLL can contain more components, there'll be more CoClasses accordingly.
Yes.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownThanks, both of you.
-
grassrootkit wrote:
* Just by knowing the component's CLSID & the interface's IDs? Use a component with the "import" directive, that takes information from the .tlb file? <-won't this require any header file?
A header file will be created during the build process that usually has the .tlh extension.
grassrootkit wrote:
* Creation using ProgIDs is efficient?
In comparison to what? The CLSID I presume. Due to how the registry is organized, using the ProgID will require an extra round-trip to find out the CLSID since it's underneath that key in the registry the path to the dll is found.
grassrootkit wrote:
* A COM DLL doesn't mean a component. A COM dll may contain any number of components inside.
Correct in the sense that a COM DLL may contain more than one COM server.
grassrootkit wrote:
* A CoClass is a component object. As a COM DLL can contain more components, there'll be more CoClasses accordingly.
Yes.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownBut what does this mean?
#import "C:\Program Files\Common Files\System\ADO\msado15.dll"
-
grassrootkit wrote:
* Just by knowing the component's CLSID & the interface's IDs? Use a component with the "import" directive, that takes information from the .tlb file? <-won't this require any header file?
A header file will be created during the build process that usually has the .tlh extension.
grassrootkit wrote:
* Creation using ProgIDs is efficient?
In comparison to what? The CLSID I presume. Due to how the registry is organized, using the ProgID will require an extra round-trip to find out the CLSID since it's underneath that key in the registry the path to the dll is found.
grassrootkit wrote:
* A COM DLL doesn't mean a component. A COM dll may contain any number of components inside.
Correct in the sense that a COM DLL may contain more than one COM server.
grassrootkit wrote:
* A CoClass is a component object. As a COM DLL can contain more components, there'll be more CoClasses accordingly.
Yes.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownAlso, my program has not generated any .tlh or .tli files. But it has created a C file with _i suffixed. like this : MyComTest_i.c. I should use this rather? Using VC8.0.
-
But what does this mean?
#import "C:\Program Files\Common Files\System\ADO\msado15.dll"
-
Also, my program has not generated any .tlh or .tli files. But it has created a C file with _i suffixed. like this : MyComTest_i.c. I should use this rather? Using VC8.0.
The extensions of the preprocessor generated files can be configured in the project settings. Different versions of MSVC seem to use different extensions. Don't worry about the *.c-file. If you want to use the typelibrary information from another file, simply include the preprocessor generated header file. A common way is to do the import in the stdafx.h file and then include the preprocessor generated header file as needed.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
The extensions of the preprocessor generated files can be configured in the project settings. Different versions of MSVC seem to use different extensions. Don't worry about the *.c-file. If you want to use the typelibrary information from another file, simply include the preprocessor generated header file. A common way is to do the import in the stdafx.h file and then include the preprocessor generated header file as needed.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown//You mean,In the project option, Configuration properties-> MIDL->Output->IID File = MyProject_i.c ? I should use this file for using with client?
-
The extensions of the preprocessor generated files can be configured in the project settings. Different versions of MSVC seem to use different extensions. Don't worry about the *.c-file. If you want to use the typelibrary information from another file, simply include the preprocessor generated header file. A common way is to do the import in the stdafx.h file and then include the preprocessor generated header file as needed.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownHey got it :).. I've used COM but not from a C++ client. So my first C++ client takes off well :D. :jig: thanks. Next is to use Connection points in a C++ client. ;) Can you point to a good article that speaks about USING connection points in a C++ client?
modified on Friday, February 20, 2009 5:41 AM