|
Hi,
I want to write Add in Or Plug-In for PDF reader files. I would like to know is it possible to write in COM / C#? If not then which language we need to use for this?
Thanks
SNI
|
|
|
|
|
Hello there,
i hope this is the correct category, to ask this question:
I am developing a Shell Namespace Extension and am currently looking for a way to command the shell, to remove a shell folder. I know there is the function SHChangeNotify, but from my understanding this just tells the shell, that stuff has happened, but doesnt make the stuff happen.
I tried to use this function for my intentions, but it doesnt seem, as if any memory gets freed and i couldnt find, that the FinalRelease()-function neither of the concerned ShellFolder nor of its subfolders gets called. At this point i may be mistaking due to the windows-explorer instancing so confusingly many objects.
Is there any other function i could use, or any different ideas? There must be another Shell Namespace Extension out there, that eventually encountered the same problem, so i cant imagine this to be unsolvable.
Thanks and greets,
Gernot
|
|
|
|
|
|
* 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!" - unknown
|
|
|
|
|
hopefully we gave the same results 
|
|
|
|
|
|
But what does this mean?
#import "C:\Program Files\Common Files\System\ADO\msado15.dll"
|
|
|
|
|
It means that you want to include type library information from the file.
Read more here[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
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
|
|
|
|
|
//You mean,In the project option, Configuration properties-> MIDL->Output->IID File = MyProject_i.c ?
I should use this file for using with client?
|
|
|
|
|
|
Hi guys,
I have COM DLL Servers creating a lot of COM objects with CoCreateInstance and it's quite slow.
I wondered if replacing the CoCreateInstance(CLSID_Foo) by a new CComObject < CFoo > would speed up things ?
Or to be clearer, how slower is CoCreateInstance compared to new operator ?
thanks !
|
|
|
|
|
Alexandre GRANVAUD wrote: I wondered if replacing the CoCreateInstance(CLSID_Foo) by a new CComObject < CFoo > would speed up things ?
No.
Since in both ways a COM object is created. Using the "new operator", as you call it, will eventually call ::CoCreateInstance(), so there's no difference.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
calling new CComObject < CThing > calls CoCoreateInstance????
i'm sure it doesnt !!
|
|
|
|
|
Alexandre GRANVAUD wrote: calling new CComObject < CThing > calls CoCoreateInstance????
i'm sure it doesnt !!
No, of course; allocating memory for a CComObject doesn't call ::CoCreateInstance().
But in order to create the server you'd have to call CComObject::CreateInstance().
Otherwise the server won't be created and your comparison wouldn't make sense at all. 
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
why do you need to call it ?
as i can see, the CCOmObject constructor call FinalConstruct, so what extra initialization do we need ?
|
|
|
|
|
You simply cannot use new to create COM objects (COM objects lifetime has its own rules  ). If you need to create multiple objects, then you may obtain a speed enhancement using directly the IClassFactory interface, see the remarks section of this page [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
yes you can in the same DLL, i do it everyday : in inprocess it's ok to do so
new CComObject < CThing > then doing a Queryinterface or a AddRef on it and your object is ok
|
|
|
|
|
And what is the rationale behind that (other than revealing your bad practices )?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
speed is always a good practice
having a bad practice is ok if you know you have (i do ) and know the consequences
|
|
|
|
|
|
lol i agree for the speed (but can't slowdown)
i don't break the com creation mechanism : the CreateInstance in a ClassFactory does exactly the same : a new CComObject<cthing> !
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
.. I've used COM but not from a C++ client. So my first C++ client takes off well 
. ![Jig | [Dance]](https://www.codeproject.com/script/Forums/Images/jig.gif)
thanks.
