|
I think that's what I'm looking for. Thanks.
J
May the bear never have cause to eat you.
|
|
|
|
|
hy, i have read a lot about this topic, but didnt found good answers. can anybody explain, how i can code the following VB-code in VC++ ?
Sub DocumentsExample()
MsgBox(DTE.Documents.Count)
End Sub
How can i get this DTE object? the compiler doesent recognises it.
I would like to make an addin for VC++.NET in which i can manipulate the code. (textmanipulations)
can anybody tell me, how i can do this? i dont know how to do things which i coud do in VB with
activedocument.selection , etc..
thanx for any input!!!
|
|
|
|
|
When you create an add-in, you implement a set of interfaces, and some of them are passed a pointer to the current DTE instance you are looking for. So you don't really have to worry about it. More info here[^].
(DTE is short for IDTExtensibility2).
|
|
|
|
|
unfortunately, i have read all written in your link before. im now working since 2 days at this problem, and i still have no idea how to solve my problem!!!! its making me crazy!
cant you give me a link to a sample add-in (in c++) of an add-in, which simply does the following thing:
clicking on the add-ins button makes, that the currently selected text in VC++.NET (or in Word, id dont care, code will be probably ca. the same)changes, or lets say will be deleted. so you can select some lines of text, click the add-in and the text will be deleted. how can i do this? it cant be this difficult, i think, but i cannot find any explanation of how to code an addin in c++, and no good sample-code
thanx a lot for any help!
|
|
|
|
|
I believe you are confusing an add-in and a macro. Why don't just record a macro, and then examine the produced VBscript code to adapt it to more general needs?
|
|
|
|
|
i dont confuse anything. i cant record a macro because 1. its not possible to records complicated things like those i want to do. 2. my boss told me he explicitly wants all code in c++.
maby i should talk to the boss 
|
|
|
|
|
My advice then is to launch VS.NET, create a new project by choosing the project wizard called "extensibility" or something like this, then choose "shared add-in". Doing so, you've got a working skeleton created for you. And one of the methods has the IDEExtensibility2 interface we've been talking about. Using this interface, you can drill down to the current Document object, and get the selection.
My suggestion is also to read this article[^] on MSDN.
|
|
|
|
|
have you checked out this and this?. While the first shows you how to implement IDTExtensibility2 in your addin, the next allows simple text addition to visualstudio via DTE.
Hush,hush...
thought I heard you call my name now.
Kula Shaker.
Amit Dey
Latest articles at CP -
PocketPC New menu
Office addin
|
|
|
|
|
is it possible to write IE plugin on a .NET(for example
on C#)?
|
|
|
|
|
Yes. Look up Cp for Custom Explorer Bar or BHO (Browser Helper Objects). I remember I have seen a couple articles about it, using C#.
|
|
|
|
|
I hope I'm not making a complete fool of my self by asking this question and that whoever reads this understands my english...
Trying to use deskbands and have reads alll tutorials and articles forward and backwards (and I have had much use of those found here so thank you) but one thing I can't make work is how to make the deskbar appear autmaticly when I start explorer. Does anyone have any suggestion, help or link? It would be very appreciented.
//Mårten
|
|
|
|
|
I would like to know how to do this too.
|
|
|
|
|
Dear All,
Well this one is a complicated one but please bare with me.
We have an ActiveX Control developed in VB which is used to interface a client DCOM component which then connects to a DCOM server component on another machine.
The application works beautifully when the user are all on the same domain. Unfortunately we need to run the application across domains... I thought ah no problem, there are two methods to fix this:-
1. create two identical local accounts (dcom_su) with same username & password. Run the DCOM Server in the username process, give the user access/launch permissions on the server machine.
Then on the client machine make sure that the user is able to access the DCOM client on the client machine, I also added the user to launch permissions for good luck.
Anyway thats as far as I got.... next I thought about the second method.
2) Setup a trust between the NT/W2k domain.(domains NT<->W2K)
So we setup a trust and then added the the user (W2K\dcom_su) that the DCOM server process was running in to the client DCOM configuration (access/launch) permissions.
We added the user account (NT\simond) that the DCOM client will be running in to the server DCOM configuration (access permissions only). The DCOM server will already be running, so no need to have launch permissions ( i did try it with launch permissions as well just in case, but fortunately it still didnt work, otherwise that would have confused me even more!! )
Anyway load up the MFC prog as NT\simond .. and it didnt work, VB app works beautifully...
AGGGHHH...
When I tested the ActiveX control, the application looks like its working and one of the methods fails due to an Access Denied message.
The funny thing is that I have a VB app which hosts the ActiveX control so I run that and guess what? .. it works fine.. so there seems to be a difference between the way that VB inits ActiveX Controls to VC++, is that true?
I am not using CoInitializeSecurity() as wanted to handle things through the registry. I also have tried to disable DCOM authentication by switching the default connection type to 'none' on the client machine as apparently VB doesnt init DCOM security(which i think is wrong as how come it works through the VB app with security on).
Anyone have any ideas?
Love to hear them..
Anything you dont understand or i have explained poorly just say.
Think this problem is more interesting than most others!!
If I find a solution then I'll post it at least then if any of you have a similar problem you wont have to go through what i have!
TIA
Simon
|
|
|
|
|
Hello all who read this,
i gotta complete a project within the next 6 hrs, one of it's requirements is to control it thru license usin ActiveX, i know it sounds mean... but i'd b really gr8full if somebody of u'd share his/her source for license control with me!
i cant xplain how big a prob this is rite now...
NOTE: A tutorial would also b a gr8 help... on how to make an ActiveX COM for license control!
aKela_sHEr
(akelasher@yahoo.com)
-Invincible
|
|
|
|
|
I'm working on a library and am getting to the point of using enumerations over objects. From some research I've done, it seems that for full [oleautomation] support, I must use IEnumVARIANT's. Is this true? If so, I might as well use the ATL templated class, such as CComEnum, huh?
If not, I would want to use my own IEnumXXXX, and have found various ways of doing such and was wondering what was best. One was a typedef in the IDL file that uses the CComEnumImpl<> templated class and that was that. In the other case, you actually define your own interface from scratch, but are left with all the details. Is there a hybrid to this approach? Perhaps using an IEnumVARIANT internally while basically using my own IEnumXXXX as a wrapper? I've looked for some decent examples (both on CP and others, like CodeGuru) but haven't found anything.
Any suggestions would be greatly appreciated. TIA
"Well, I wouldn't say I've been missing it, Bob." - Peter Gibbons
|
|
|
|
|
Hi,
I have a client that (for example) does various effects on a given graphics file. My client needs to call a method called DoEffect(). What I want to do is provide one or more COM servers to provide the effects which would then allow others to add effects by simply building their own COM server with a DoEffect() method.
Using component categorisation, I can place my "effect servers" in a component category and my client can discover them at run-time - it will simply list a set of prog IDs or CLSIDs. Additionally, it would allow others to build their own effect servers and as long as they use the effect server categorisation, my client will list them as being able to be used.
What I want to know is how best to design my effect COM servers? Should I provide them all with an interface called (say) IEffect and then should I be able to call the DoEffect() method from the interface pointer? I guess the interface point can be derived easily enough from the PROGID/CLSID listed by component category...
Thanks for any info you can share on this
|
|
|
|
|
Yes, that's very easy - after you discover the PROGID/CLSID of the required effect component, you can call CoCreateInstance, passing the CLSID and asking for IEffect interface. Then, if the interface is known to the object you want to create, you will get directly IEffect pointer for using.
Then one simple call of the IEffect::DoEffect() method and you can release the object (or save it for later use...)
Later on, when you will need to extend your effect modules by changing the method or its parameters, you have to develop new interface, say IEffect2. Then the steps will be the same as above, but after you will have the IEffect interface, you should use QueryInterface for retrieving the IEffect2. If this step fails, it is simply some old effect object, without new features support, so you will use the old IEffect::DoEffect() way of calling.
Is that you are asking for? (frankly, the last sentence
Anonymous wrote:
I guess the interface point can be derived easily enough from the PROGID/CLSID listed by component category...
wasn't quite clear to me)
|
|
|
|
|
Thanks for the reply
Well, now I have a client (my effects browser). I have three effect COM servers, each declaring a "IMyEffect" interface, with a method "GetName()" which simply returns the name of the effect it provides.
In each COM server, I have over-ridden the default GetCategoryMap() method and added a category map to my coclass which specifies a single implemented category using a single defined CATID (in a header file accessible to all my COM servers).
In my effect browser client I've implemented code to simply list all the progIDs/clsIDs which it does successfully!
OK, now what I want to do is call the GetName() method on each and surely I should have enough information just from the CLSIDs but that's just my problem!
Normally, I'd call the CoCreateInstance method, specifying a CLSID (well I've got that, so that's OK), a reference to the interface identifier and an interface pointer in which to return a pointer to the interface on which I want to call the method!
That's now the problem though. Normally, I'd declare a pointer to the interface but I need access to the appropriate header file, likewise I also need the IID but again I need the header file. The problem is of course, I don't know which header file to include because the whole point of the browser is to select the COM server dynamically!
OK, I believe there's certain fundamentals of using COM which I'm just not grasping, but I'm close I hope
I'm wondering if:
a) there's some magical way of calling QueryInterface() to return what I need though from what I can tell, I still need an IID to specify (can I get the IID from the CLSID?). And what then about the IMyEffect pointer? I'd still have to have access to a header file!
b) I need to create a COM server defining the IMyEffect interface, then allow my effect COM servers to aggregate it and implement the actual methods themselves.
(b) sounds the most promising to me (what do you think or have I misunderstood even further how COM is supposed to work?). I could then have a header file which contined the single IID of IMyEffect and a declaration of the IMyEffect interface. Unfortunately, how do I then categorise the interfaces so that my browser can "discover" all the available effect servers at run-time?
|
|
|
|
|
Hi,
Normally I am using the other way around, as I consider the browser app to be the controlling part, the IMyEffect interface is defined in here (either directly in the exe's IDL if any or in some of the DLLs supplied directly with it - say default plugin). This normally produces the tlb file somewhere. You have to store this tlb - this is your header.
Then when you need to develop some plugin, you refers to the tlb file, receiving all required declarations:
in IDL file of the newly developed plugin:
<br />
library SOMEPLUGINLib<br />
{<br />
importlib("stdole32.tlb");<br />
importlib("stdole2.tlb");<br />
<br />
importlib("\Projects\Tlb\plugin.tlb");<br />
<br />
[uuid()<br />
]<br />
coclass SuperNewPlugin<br />
{<br />
[default] interface IMyPlugin;
}<br />
<br />
Be aware, that the IDL compiler uses different paths for searching the tlb files (at least it seemed that for me some versions later, since then I use absolute paths here)
When you need to generate the C++ part, there is very usefull directive #import "plugin.tlb" see documentation for more options with this directive (I consider some of them usefull). Then this generates the header for you and includes it into the compilation chain (In fact, it behaves as normal include)
Optionally you can refer directly the dll file instead of tlb, result is the same
This import creates some .tlh and optionally .tli files in your Debug (Release) folder, so you can inspect what actually is here. It should contain the interface definition and all IIDs and CLSIDs defined in the plugin.tlb
So then the usage is something like that:
<br />
#import "\Projects\Tlb\plugin.tlb" raw_interfaces_only, raw_native_types, no_namespace, named_guids <br />
<br />
class ATL_NO_VTABLE CSuperNewPlugin : <br />
...<br />
public IDispatchImpl<IMyPlugin, &IID_IMyPlugin, &LIBID_WHERE_THE_PLUGIN_IS_DEFINEDLib>,
...<br />
The rest remains the same...
Hope it is somehow clear, if not don't hesitate to ask more 
|
|
|
|
|
Finally got my login from my other machine (I hate posting anonymously)! Glad to meet you Geo, phykell here!
OK, what I decided to do was have my browser client (EffectBrowser), and have a separate server, "Effects", to hold the IEffect interface (same as "IPlugin" in your example) and make it available to all plugins and the browser of course.
I created an ATL server and defined a new class as an "ATL Class". The class name is "Effect", the interface type is "custom" and there's a single interface associated with it, "IEffect". I then added a method to the interface, "GetName", returning me a *BSTR. That project builds with no problems, registers and gives me a type library "Effects.tlb"
So, I then create my plugin as an ATL server, "EffectServerMosaic". I add a new ATL class with the name "EffectMosaic". It has a custom interface called "IEffectMosaic". I then import the Effects.tlb into the EffectServerMosaic.idl file and I change the EffectMosaic coclass' default interface to "IEffect" (defined in my imported type library). I then add a category map to my EffectMosaic coclass. My ATL server builds and registers successfully.
Note at this point, I haven't implemented a method GetName() for my plugin which I guess is necessary to over-ride the one provided by my plugin's coclass' default interface "IEffect". Is that right because if so, how come the compiler hasn't generated an error *requiring* me to provide an implementation?
So far so good (I think)
Finally I create my EffectBrowser application. I place the necessary code to get a list of all coclasses with the required category map and I prove this by displaying the retrieved ProgIDs derived from the CLSIDs (I presume these CLSIDs/ProgIDs are of each coclass). For example, one ProgID I get is displayed as:
EffectServerMosaic.EffectMosaic.1
I then try and create an instance of one of these coclasses (so that I can try and call the GetName() method on them. Unfortunately, I get an error message "REGDB_E_CLASSNOTREG" class not registered.
Here's the code I use to try and create the instance:
CLSID myCLSID = clsid[0];<br />
IEffect *pMyEffect = NULL;<br />
hr = CoCreateInstance(myCLSID, NULL, CLSCTX_ALL, IID_IEffect, (void **)&pMyEffect);
Note that IEffect and IID_IEffect are pulled in from the following #includes:
#include "..\Effects\Effects_i.c" <br />
#include "..\Effects\Effects.h"
Clearly, if I'd tried to create an instance using a pointer to the IEffectMosaic interface and the IID_IEffectMosaic ID, it would've have succeeded. I thought I'd be able to call the plugin's methods by getting its ProgID and using it's default interface or do you think I've made a fundamental mistake somewhere (I certainly do!)...
Lastly, I didn't understand what you meant when you said "need to generate the C++ part" and what you meant when you recommended using the #import diective.
Thanks again for your help, and sorry this is taking so long
"The folly of man is that he dreams of what he can never achieve rather than dream of what he can."
|
|
|
|
|
Well, so first to your question,
phykell wrote:
Note at this point, I haven't implemented a method GetName() for my plugin which I guess is necessary to over-ride the one provided by my plugin's coclass' default interface "IEffect". Is that right because if so, how come the compiler hasn't generated an error *requiring* me to provide an implementation?
yeah, you need to implement all the methods specified in the interface. That's simply because in interface all methods are virtual with PURE specification. So you are right, compiler should generate an error. If he didn't do so, he probably found some implementation somewhere or it might be, you didn't change the class declaration for deriving the class from the interface.
But we can do it other way. Briefly - you have the tlb definig the interface IEffect and you have some object wanting to implement this interface.
So choose the class view in your devstudio, right click on the class you want to implement the IEffect interface (I guess CEffectMosaic) and select Implement interface (in msvc.net it is Add/Implement interface). Here you have to select the IEffect somehow. I guess the wizard is self explanatory, but if you'll have difficulties, I am mostly allways here.
If gods will be with you and the wizard will not crash, you'll have all done - your class is derived from the IEffect interface, it should be written between BEGIN_COM_MAP and END_COM_MAP and all this work it have to do. You have now only to add the Category stuff.
So let's go on - why the CoCreateInstance returns the class not registered? Hmm, difficult to say - I would check, if you pass correct CLSID to it. Also here I would suggest to use the smart pointers - it will simplify your code and take care about addref/release things. Then the code will looks like somehow like that one:
<br />
CComPtr<IEffect> spEffect;<br />
hr = spEffect.CoCreateInstance( myCLSID );<br />
Then I would try to directly create one specified plugin - spEffect.CoCreateInstance( CLSID_EffectMosaic(?) ) this could help to find the problem...
#import part. well... you included the IEffect from the Effects.h. This is OK, but now imagine, that you have no access to it for any reason, not important now. So instead of
<br />
#include "..\effects\effects.h"<br />
you can use
<br />
#import "effects.tlb" + modifiers
and you'll achieve the same goal - in fact the effects.h and effects_i.c are generated again here (or something very similar). Then the choice is on the developer what he will prefer. The Add Interface wizard uses the #import part.
Hope this helps you a bit more.
|
|
|
|
|
It's working! Thanks very much for your help, it's greatly appreciated!
Perhaps I should write my first article on this very subject, with the appropriate credits of course
The "implement interface" wizard worked just fine and simply let me browse for the type library I wanted to import. Once I'd built the code I could see exactly where I was going wrong previously, and it turned out I was very close (but no cigar as they say).
Anyway, thanks again Geo 
"The folly of man is that he dreams of what he can never achieve rather than dream of what he can."
|
|
|
|
|
If I try and create an interface called IInternet as part of my COM server, I get the following compiler error:
Error C2440: 'static_cast' : cannot convert from 'class CInternet *' to 'struct IDispatch *' - Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
I guess this means I can't just use any name I please for an interface - and I thought only IUnknown wasn't to be used!
Is there some way round this and is there also a definitive list of what interface names would cause a clash?
Thanks.
|
|
|
|
|
Heh, bad luck . There is no such a list of "Interface names you cannot use". For the system the name is actually represented by the IID - some big ugly number. For the system itself is no problem to have ten or whatever number of IInternet interfaces, as long as they will have different IID.(see OLE/COM object viewer, in the tree is a branch Interfaces, I'm sure you'll find here some duplicate interface names, but not IIDs).
Problem what you have, is in your compiler - because one IInternet is included in header urlmon.h (this is included through ATL as well as through MFC headers) and one is in header generated from your IDL file. Then, your compiler have 2 different IInternet definitions. But he doesn't care about some IID, for him it is simply the collision, but it is the same collision as having say two base classes with the same name.
Solution - you can simply rename your IInternet to something else, or you have to avoid the urlmon header. For this Microsoft guys use #define __urlmon_h__. But don't know the dependencies in your code, so cannot say if the second option will work.
Maybe after some elaboration, there will be some possibility to place the names to different namespaces. But I am normally not using the namespace thingie, so I cannot help you here much.
Hope this helps
|
|
|
|
|
Hi, thanks for the reply
I totally see that now. Sure enough, it is clashing with IInternet declared in urlmon.h. Trouble is, in my COM server which is going to be providing internet services, it will definitely have to use the IInterent services (wrapping some of them up I suppose). I guess I'll just have to use a more specific name as you suggest.
Interestingly, I was led down the wrong path by the error I reported above. I tried creating another COM server with an interface defined in it called "IModule" and got the same error. I then wondered if there's an IModule interface declared in some header like IInterface, but I haven't found one. I then wondered if it's because I'd created another COM server with an IModule interface but as you correctly point out (and as I also believed) the system differentiates by CLSID (and IID) not interface name. Anyway, I then tried creating three COM servers as Effect objects (from my other post above) and defined a "IMyEffect" interface on each. The first one built with no problems but when I was building the second one, I got a dialog box saying that it was already defined in the registry and did I want to use the existing CLSID or not. I replied no of course. I thought then that yes, the system was aware of interface names and not just IIDs then! Stranger still was that when I repeated the creation of yet another effect COM server and created another ATL object declaring the same interface "IMyEffect" I didn't get a repeat of the message asking if I wanted to use the existing CLSID! Hope you followed all that!
The namespace idea is interesting, I'll follow this up, thanks.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
