 |
|
 |
Hello.
I am new to Com programming..
I have to make an COM aplication which fires some messsage(Asyncronusly) upon some task comletion,And that message I have to handle in VB 6 Application...
I know about SendMessage & PostMessage function available but for that I dont know how to handle that USER DEFINED messages (event) in VB application.
So..If you have any idieas or in COM is there any Interface which will Provide this kind of thing plz replay me..
Thanks in Advance.
Jagdish
|
|
|
|
 |
|
 |
I appreciate the articles and the source code. It has been very useful to me as far as using C++ to call COM methods.
However, I was looking for something a little more specific with this article that I didn't get out of it.
I was really anticipating a function in the console app to be called when events get fired. Unfortunately, I am just not bright enough to figure out how to do that with what I have here. Any help would be greatly appreciated.
-TS
|
|
|
|
 |
|
 |
Travis Smith wrote:
I was really anticipating a function in the console app to be called when events get fired.
It is not easy to do that using the code I provided here. This is my experiment with com events, it can be hacked to do what you want but it is definitely not the easy way and not for beginners.
Good luck.
My articles and software tools
|
|
|
|
 |
|
 |
Hello,
I have written a COM addin in C++. I face a challenge of needing to send a message (much like pWnd->PostMessage(...) in CWnd) in the COM add in environment. Any way of achieving such effect?
thanks.
Sonork 100.41263:Anthony_Yio
|
|
|
|
 |
|
 |
I do not understand why it is called "Handling COM Events in a Console Application", you see, it can be called "Handling COM Events in a window-ed Application". What you try to resolve is actually "Handling COM Events in non-MFC App".
At this point, it is a trash...
|
|
|
|
 |
|
 |
Anonymous wrote:
I do not understand why
How smart people become even smarter? Here is a tip:
Forget what you understand
Learn what you don't
--- The Smartest
My articles and software tools
|
|
|
|
 |
|
 |
I am a very begineer. I tried to ur class. I was able to get the dispatch Interface but when I was trying to call invokeMethod("MyMethod","String",&int). I am getting the subjected HRESULT.
Proto for my Method
-------------------
HRESULT EnumerateDevices (_bstr_t GUIDDriverInterface,
int * NumberOfDevices );
When I checked more..... I saw it was getting the Type of the Second Parameter as 0x4016 is this a valid Type.
Thanks in advance
Asim
Mohammad Asim
|
|
|
|
 |
|
 |
Your method name and parameter type should match exactly (with the com object). You can step into the code to see exactly which line is causing the problem, see if the com object threw an exception or not.
My articles and software tools
|
|
|
|
 |
|
 |
Thanks,
But with a normal client of MFC based application was successfully able to call all of the member function of ActiveX dll Server. I also have checked through debugging, there was not any com exception the BSTR String type was successfully transferred with right type identification. but the Pointer to long was getting the Parameter Type ID as 4xxx (some thing) this is the only curious thing since I could not find this type ID in your code to be any valid type. so I think the Variant is not properly initialized with the pointer to long. For me it looks that this is the only problem causing HRESULT to be the subjected result. what do you suggest?
Thanks for posting this good article and I am also using your XYMessenger Product for my next Network based application that will be a portal of Software Management on our Corporate intranet Software Management.
Thanks again for posting good articles on CodeProject. This site really helps me a lot coz of you guys are the backbone of this side.
Mohammad Asim
Mohammad Asim
|
|
|
|
 |
|
 |
Mohammad Asim Shaikh wrote:
Thanks for posting this good article and I am also using your XYMessenger Product for my next Network based application that will be a portal of Software Management on our Corporate intranet Software Management.
I am glad to hear that. Thanks.
I did some checking into the Microsoft header files. Since VT_BYREF = 0x4000, VT_I1 = 16, we have
(VT_BYREF | VT_I1) = 0x4016
So the parameter type in question is actually char* (point to character) instead of int* (pointer to integer). Can you try the new type and see if it works?
Good luck.
[Edit] You can find values of all the VT_ types in the header file wtypes.h [/Edit]
My articles and software tools
|
|
|
|
 |
|
 |
if you also aware of that u are a sh*t coder, then be kind stopping posting stupid stuff on CP.
... but keep on posting ASP and VB here for you seems not a C++ guru...
besides do not dispute this points, you ass hole usually thought you are right
|
|
|
|
 |
|
 |
-
|
|
|
|
 |
|
 |
I've a question about this example: It opens excel and inserts an eventsink to catch the events inside excel.
HOWTO: Catch Microsoft Excel Application Events Using VC++ Q186427
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q186427
I've tried this example using an MFC-EXE, and all works fine. When you press start, the excel application shows up. Clicking with the mouse results in a event messagebox.
But, if you want to include this functionality inside an MFC-DLL, it will not work. Excel shows up alright, but when you click something or press a button, the excel application will block. After a while a messagebox shows up saying: "Microsoft Excel is waiting for another application to complete an OLE action."
Short: using a .exe works fine, but the .dll blocks.
Why?
What's the difference here? (I've used MFC in both cases)
[VISUAL STUDIO 6.0] [MFC] [WIN98/2]
Bluute tette!
|
|
|
|
 |
|
 |
Hi,
Check out this sink examples i created: http://homepage.eircom.net/~codexpert/sink/
Regards,
|
|
|
|
 |
|
 |
I downloaded and looked at your classes. They are great.
You really should write an article and post it here.
Just want to point out that my class XYDispDriver focuses on "late-binding". That's why I need to create the "Event Handler Control". If I know the prog ids of the com control and its event handler, I can write code to dynamically (not at compile time) create them both and hook them together.
Thanks for the link.
|
|
|
|
 |
|
 |
Hi Xiang...
I just wish i had enough time for articles and all...
For OCX COM servers the best way to utilize their events is through MFC native support, when you say Project->Add to project->Components and Controls, select your OCX. You'll get a CWnd derived class to represent your OCX interface. Then in a client object use something similar to this:
BEGIN_EVENTSINK_MAP(CTreeToolBar, COXSizeControlBar)
ON_EVENT_REFLECT(CTreeToolBar, 1 , OnSiteListMouseClickEvent, VTS_I4 VTS_I4 VTS_I4 VTS_I4 VTS_I2 VTS_I4)
ON_EVENT_REFLECT(CTreeToolBar, 2 , OnSiteListSelectEvent, VTS_I4 VTS_I4 VTS_I2 VTS_I2)
ON_EVENT_REFLECT(CTreeToolBar, 4 , OnSiteListForEachEvent, VTS_I4 VTS_I2 VTS_I4 VTS_I2 VTS_I4)
ON_EVENT_REFLECT(CTreeToolBar, 7 , OnSiteListGetListEvent, VTS_I2 VTS_BSTR VTS_BSTR)
ON_EVENT_REFLECT(CTreeToolBar, 8 , OnSiteListGetTreeItemEvent, VTS_I2 VTS_I4 VTS_BSTR VTS_BSTR VTS_BSTR)
END_EVENTSINK_MAP()
In the class declaration use macro DECLARE_EVENTSINK_MAP()
An alternative would be to use ATL, and then yes, it will be the same as in my example.
Regards,
Vitaly Tomilov
Professional tooltips for all development platforms Free on www.Tooltips.NET
|
|
|
|
 |
|
 |
Chopper wrote:
For OCX COM servers the best way to utilize their events is through MFC native support, when you say Project->Add to project->Components and Controls, select your OCX. You'll get a CWnd derived class to represent your OCX interface.
Actually, this is not going to work for me in many situations. I am trying to handle com events for windowless com objects and avoiding MFC (and ATL) at the same time. So far I only showed that if you can create a windowless com object (or control) that implements the event interface, then you can use my class to handle the event.
Of course, it is not the most easy or preferred way for a lot of people.
Good luck.
Click here to see my articles and software tools
|
|
|
|
 |
|
 |
I wonder why Microsoft does not document such things, I spent complete 10 hours to know how to do this, have to do lots of R & D and permutations and combinations of methods to get something.
Examples supplied with Visual Studio are almost useless.
However, thanks a lot, this was not I actually looking for but it will be useful somewhere sometime.
Programming is fun.
-Akash Kava
|
|
|
|
 |
|
 |
Fixed the project file so that it compiles under both VC++ 5.0 and VC++ 6.0.
|
|
|
|
 |
|
 |
So, what's the benefit???...
OK, you are using late binding to sink on events and that's as well known the only way to do that...
However, I'm lost => why do you need a registered component (your Handler object) to do that??? Only to accomodate your COleDispatchDriver derivation???...
It's obviously not the best way considering overhead involved during runtime as well as necessity to register your hadler components... when you only need in reality 5 functions of IDispatch... Also, don't forget, that Connection point container, may query for GUID of your implementation of the outgoing intarface (ATL does that) => meaning any delegated, derived and etc. outgoing interfaces will force you to write different Handlers for different GUIDS????...
Anyway, I agree with others that you man is trying to invent something EXTRA complicated...
|
|
|
|
 |
|
 |
igor1960 wrote:
So, what's the benefit???...
OK, you are using late binding to sink on events and that's as well known the only way to do that...
However, I'm lost => why do you need a registered component (your Handler object) to do that??? Only to accomodate your COleDispatchDriver derivation???...
It's obviously not the best way considering overhead involved during runtime as well as necessity to register your hadler components...when you only need in reality 5 functions of IDispatch...
What I am demonstrating here (which can be a well-known fact, depending on who you are talking to) is that event interface is just another com interface. So what's more natural to handle events than implementing a com object? What runtime overhead are you talking about? Ok, you have to register the event handler at-least once and you have to call CreateObject when the program is started, but after that it's just IDispatch::Invoke.
The benefits? Consider the simplicity and flexibility of this method. Now your event handler is a separate com object which is more loosely coupled with the rest of the code. You can, for example
1. plug-in a different com object to handle the events.
2. plug-in multiple com objects to handle the same events.
3. even make some of your event handlers run from a separate process/machine (see my other article for details).
4. choose your favorite tool to implement the event handler (MFC, VB, ATL, or strictly com api, whatever you prefer), it is really no big deal.
igor1960 wrote:
Also, don't forget, that Connection point container, may query for GUID of your implementation of the outgoing intarface (ATL does that) => meaning any delegated, derived and etc. outgoing interfaces will force you to write different Handlers for different GUIDS????...
Anyway, I agree with others that you man is trying to invent something EXTRA complicated...
It is fine with me if you think my method is unnecessarily complicated or even useless, as long as you don't tell me to shut-up. I never thought my method is perfect, as a matter of fact, readers who are using my code helped me to improve it a lot.
But some so-called ATL experts feel that they have to defend ATL against my method, which makes me feel flattered. What are they afraid of? That one day people will abandon ATL in favor of my method? I think I just came up with some good ideas for a Halloween movie for thse guys, time to give Steven Spielberg a call ...
|
|
|
|
 |
|
 |
I'm an MFC guy... And was him since MFC inception...
However, you are mixing up keywords as if this is relevent...
All advantages of sinking on COM outgoing interfaces are common to either ATL, MFC, VB and/or etc. implementations and can be done in any language(system), as far as this implemetation supports COM...
Sure, it's a free country and you are free to implement whatever you want...
Even, more your implementation maybe valid for some or any particular cases (I can't imagine for what though)...
However, make generalizations like you are doing is not right...
When you are saying that "event interface is just another com interface" => you abolutely right => however, who said that it has to be IDispatch derived??? And your implementation assumes that!!!...
Also, when you are saying "you have to register the event handler at-least once and you have to call CreateObject when the program is started" => Why should I have to register anything if I only need Invoke??? As well as => do you know that ConnectionPoint Advice does AddRef on your interface => So, why do you need to CreateObject at all??? Again, just a few examples that the whole idea you are presenting is hypothetical and has no real meaning...
When you are saying that you can "plug-in a different com object to handle the events" => you are assuming that each of them will use same IDispatch implementation as an outgoing interface => so you are loosing here an advantage of interpretive Invoke implementation and late binding...
You can continue writing your articles of cause => but my advice man => you better get some books first and read a little...
For example it would be nice if you could figure out who is Client and who is Server in proposed by you implementation and after that give me an answer if your control object is a Server and if your Handler is a client => what is your program name???!!!....
GL...
BTW => cVars question was mine....
|
|
|
|
 |
|
 |
igor1960 wrote:
I'm an MFC guy... And was him since MFC inception...
However, you are mixing up keywords as if this is relevent...
All advantages of sinking on COM outgoing interfaces are common to either ATL, MFC, VB and/or etc. implementations and can be done in any language(system), as far as this implemetation supports COM...
Sure, it's a free country and you are free to implement whatever you want...
Oh, you are an MFC guy. I was ranting because I had been called from "unprofessional" to "stupid" by others. I was mistaken thinking you are one of "them", sorry about that.
igor1960 wrote:
Even, more your implementation maybe valid for some or any particular cases (I can't imagine for what though)...
However, make generalizations like you are doing is not right...
When you are saying that "event interface is just another com interface" => you abolutely right => however, who said that it has to be IDispatch derived??? And your implementation assumes that!!!...
I am just glad that I am right for something!
My ideas were motivated by practical needs. We have a lot of console apps (Tuxedo 6.5 servers) which need to use third party or in-house com objects. My class will make it possible for us to use com objects and handle com events without redesign the apps from scratch. The code is so simple, a lot of developers on the team don't even notice that we are using a lot of com objects. By the way, how would you approach this problem, in case you are familiar with Tuxedo servers?
Yes, the XYDispDriver class does depend on the IDispatch interface. But as soon as I change the signature of the XYDispDriver::Advise method, you will be able to use other event interfaces not derived from IDispatch (and not created by XYDispDriver). See, you just made another valuable suggestion.
igor1960 wrote:
Also, when you are saying "you have to register the event handler at-least once and you have to call CreateObject when the program is started" => Why should I have to register anything if I only need Invoke??? As well as => do you know that ConnectionPoint Advice does AddRef on your interface => So, why do you need to CreateObject at all??? Again, just a few examples that the whole idea you are presenting is hypothetical and has no real meaning...
When you are saying that you can "plug-in a different com object to handle the events" => you are assuming that each of them will use same IDispatch implementation as an outgoing interface => so you are loosing here an advantage of interpretive Invoke implementation and late binding...
You can continue writing your articles of cause => but my advice man => you better get some books first and read a little...
In my method, a console app creates both the com object and its event handler object, it can also call unrelated methods in either of these objects. Yes, CreateObject is called in addition to Advise. It gives me the flexibility I want so I don't consider it a huge deal.
I just built the ATL event handling sample project that comes with MSDN. Guess what? The project is implemented as a com dll and you have to register it in order to use it! So even Microsoft does not consider registering the event handler object a big deal. One difference I have to point out, the ATL sample creates the event source object from within the event handler object, that makes it easier to call its methods from the event handler functions but makes it a little harder if you want to use another event handler to receive events from the same source (I am sure there is a way to get around this though).
Thanks for your advice. I do read books (sometimes), I ain't that arrogant.
igor1960 wrote:
For example it would be nice if you could figure out who is Client and who is Server in proposed by you implementation and after that give me an answer if your control object is a Server and if your Handler is a client => what is your program name???!!!....
GL...
It seems that I always mix up clients and servers, sometimes on purpose. If you are complaining now, wait till you see my "XYSystem Components" from my home page.
igor wrote:
BTW => cVars question was mine....
A big THANK YOU.
|
|
|
|
 |
|
 |
I have actually done a lot of work in this area, and your technique seems pretty convoluted to me. For instance, where exactly are the events coming in to the console app? I don't see any entry point functions at all. It looks like your IDispatch wrapper class is simply alerting of events via message boxes. Maybe I'm missing something, but if that's as close as my console app can get to receiving events, than this is a poor design indeed.
(Sigh) I guess it's time for me to write an article.
Andy
|
|
|
|
 |
|
 |
"I have actually done a lot of work in this area, and your technique seems pretty convoluted to me."
Maybe you have done too much work in one particular way (event sink/map/entry macros, etc.) for too long that you think that is the only way to do it?
"For instance, where exactly are the events coming in to the console app? I don't see any entry point functions at all. It looks like your IDispatch wrapper class is simply alerting of events via message boxes."
That is ABSOLUTELY NOT the case. To summarize:
1. The ActiveX control that fires events is created in the console app by the XYDispDriver class.
2. The event handler written by the user, which is another ActiveX control, is also created in the console app by the XYDispDriver class. This event handler control implements the event interface in the first control, events fired by the first control are supposed to be handled in the second control.
3. Then the two controls were "connected" together so that whenever an event in the first control is fired, the corresponding method in the second control will be called. The message box is just there to "prove" that the second control received event from the first control.
Have I made myself a little more clear? If not, my apologies.
"Maybe I'm missing something, but if that's as close as my console app can get to receiving events, than this is a poor design indeed."
If you want a function defined in the console app to be called when an event is fired, that is ok too: Remember you can add extra methods to the second control (the event handler) so there is nothing to prevent you from passing function pointers into it and make it call these functions.
Judging from your reaction, I am sure you won't like this method, but please keep an open mind (someday you might need it).
"(Sigh) I guess it's time for me to write an article.
Andy "
Yes, please do.
Have a nice day.
|
|
|
|
 |