Dear Lim, thank you for trying to help. I caused the problem by not defining the right order of parameters. Vita stated in his posting (one message entry below yours) that "The arguments in the array should be placed from last to first". As soon as I read his posting I understood that I had overlooked this requirement, which for itself is sad enough...! Defining it the proper way fixed my problem. Thank you again, Rubi :-)
Ro_land
Posts
-
COleDispatchDriver.InvokeHelper PROBLEM -
COleDispatchDriver.InvokeHelper PROBLEMDear Vita , thank you so much for helping me solve the problem. The reason was in fact the order by which the args were defined , I had overlooked the requirement that , as you stated : "The arguments in the array should be placed from last to first". After having fixed this , everything works out fine now . Thank you, Rubi :-D
-
COleDispatchDriver.InvokeHelper PROBLEMHi ! my problem is as follows: I have a COM module ( COM_A) written in C++ which receives several [IN] parameters and returns [OUT] parameters. One of the input parameters is defined as [in] VARIANT vArrIn. One of the output params is defined as [out] VARIANT *dArrOut. There is no problem when I make the call directly to the respective method ! The problem arises when I try to call COM_A by means of a second COM module (COM_B), which makes use of the COleDdispatchDriver class. When I call COM_A from within COM_B by invoking InvokeHelper, the call fails and the return code says something like : "stub received bad data ...". I found out that : 1) If there is a normal [in]int parameter AFTER the [in]VARIANT vArrIn, , the call fails. 2) if I invert the order of the params [in]int iVal, [in]VARIANT vArrIn, the calls succeeds. 2)Anyway, it never succeeds when there is an [out] VARIANT *dArrOut after the [in]VARIANT vArrIn parameter. Why is this happening ? Is it possible to do it this way ? Can someone please shed a light on this. I tried out many different possibilities, including trying to define the [in]VARIANT as a pointer and to define the [OUT] VARIANT* array as [in,out], it all wouldn't help. Please help , because I need to find a solution. Thanks in advance, Rubi
-
How to receive Events from VB OCX ?I am using an OCX ActiveX control which was written in VB within my MFC project. After successfully inserting the OCX into my project, I can use the few methods declared within it and can use them successfully. My problem is : I don't see the Event , that OCX is able to raise.The function just doesn't appear in the interface class the wizard created, to help me use the OCX. How can I intercept the raised Event ? Rubi
-
UpdateCommandUI problemThank you !
-
UpdateCommandUI problemHi ! My problem : I created an application which implements 3 splitter windows. The problem is that I do not receive Update command UI messages for one of the views , thus causing my toolbarbuttons to stay disabled to begin with. What is the problem ? Please help, Rubi
-
Hooked MDIChild window ---> problemThanks , but I should have explained better. What I needed to achieve was a way to cause my DLL to plug into an existing application by some other programmer, without having to involve the the other programmer .This way , he wouldn't have to change a bit. There would be only his application with a few MDI child windows created by him, while I hook up to those MDI child windows, I induce the creation of different toolbars for the respective MDI child and intercept all the messages to those windows, thus taking over the MDI children. I achieved it, everything works fine now. As I explained in the former posting, I do receive the rerouted messages. The WM_COMMAND message cannot be intercepted by me, it is intercepted in the MDI child, but I found a way around it. Whenever I create the toolbar, I keep record of the amount of buttons and record the rectangles within the toolbar, where they are located. Now, I need just to catch the WM_LBUTTONDOWN and ..BUTTONUP messages, thus enabling me to detect which button was pressed and take action... Works great ! Thank you for your interest ! Rubi
-
Hooked MDIChild window ---> problemHi ! I managed to hook a MDIChild window to a class of mine, which is derived from the class CHookWnd , supplied by J.P.Naughter (see article http://www.naughter.com/hookwnd.html) I additionally do attach a Toolbar programmatically to the hooked MDIChild window, all works fine, meaning that 1)the toolbar is created and attached, 2) the messages are rerouted to my WindowProc. There is one problem , though: I am not able to intercept the WM_COMMAND message sent, whenever I click on one of the toolbar buttons, this message is sent directly to the child and not rerouted. I also DO NOT want to induce a redirection of the message from within the MDI child window, that would be pointless in my case. QUESTION : How can I intercept the WM_COMMAND messages issued upon clicking the toolbar buttons such, that they will be redirected automatically to my WindowProc procedure. The whole project is available upon request, thanks to anyone trying to help, Rubi
-
ATL support to existing MFC applicationFirst of all thank you "FearlessBurner" for your interest and swift response ! I finally found the bug , which caused my "COM EXE Server / MFC Doc View hybrid" not to register properly. A line of code is missing in the Microsoft sample code (can happen, of course) . Here is an extract of the inserted code section from article Q175190, inluding the missing line (indicated as such).After inserting the line I stopped receiving the "Class not registered" error messagbox alerts (caused by the missing line "OBJECT_ENTRY(CLSID_ImageProcess, CImageProcess)") : CExeModule _Module; LONG CExeModule::Unlock() { LONG l = CComModule::Unlock(); if (l == 0) { #if _WIN32_WINNT >= 0x0400 if (CoSuspendClassObjects() == S_OK) PostThreadMessage(dwThreadID, WM_QUIT, 0, 0); #else PostThreadMessage(dwThreadID, WM_QUIT, 0, 0); #endif } return l; } BEGIN_OBJECT_MAP(ObjectMap) OBJECT_ENTRY(CLSID_ImageProcess, CImageProcess) <--- ----------------------------------------------MISSING LINE END_OBJECT_MAP() LPCTSTR FindOneOf(LPCTSTR p1, LPCTSTR p2) { while (*p1 != NULL) { LPCTSTR p = p2; while (*p != NULL) { if (*p1 == *p++) return p1+1; } p1++; } return NULL; } Source code available to anyone requesting (Client and server demo applications) Send your email address... Rubi
-
ATL support to existing MFC applicationThanks...
-
ATL support to existing MFC applicationHi all ! I was assigned a task which I don't think is possible to do. What I was requested to achieve is basically the following: To cause our existing MFC (Doc/view) application to become a COM EXE server ! Is it possible at all, or am I wasting my time. If it's not possible, what approach shall I take? I used the information which appeared under the article : Article ID :175190 Last Review:June 29, 2004 Title : How to add ATL support to an MFC EXE Link : http://support.microsoft.com/default.aspx?scid=kb;EN-US;175190\[^\] Outcome so far : NOT Successful, meaning, the registration is not failing, but the server cannot be found by a client application (class not registered !) As far as I understand , the article 175190 discusses the option of embedding an "local In-process COM server" into the application, not a "remote COM EXE server". I tried everything I know, so far with no results.. Please help, Rubi
-
ATL support to existing MFC applicationHi all ! I was assigned a task which I don't think is possible to do. What I was requested to achieve is basically the following: To cause our existing MFC (Doc/view) application to become a COM EXE server ! Is it possible at all, or am I wasting my time. If it's not possible, what approach shall I take? I used the information which appeared under the article : Article ID :175190 Last Review:June 29, 2004 Title : How to add ATL support to an MFC EXE Link : http://support.microsoft.com/default.aspx?scid=kb;EN-US;175190\[^\] Outcome so far : NOT Successful, meaning, the registration is not failing, but the server cannot be found by a client application (class not registered !) As far as I understand , the article 175190 discusses the option of embedding an "local In-process COM server" into the application, not a "remote COM EXE server". I tried everything I know, so far with no results.. Please help, Rubi
-
ATL support to existing MFC applicationHi all ! I was assigned a task which I don't think is possible to do. What I was requested to achieve is basically the following: To cause our existing MFC (Doc/view) application to become a COM EXE server ! Is it possible at all, or am I wasting my time. If it's not possible, what approach shall I take? I used the information which appeared under the article : Article ID :175190 Last Review:June 29, 2004 Title : How to add ATL support to an MFC EXE Link : http://support.microsoft.com/default.aspx?scid=kb;EN-US;175190[^] Outcome so far : NOT Successful, meaning, the registration is not failing, but the server cannot be found by a client application (class not registered !) As far as I understand , the article 175190 discusses the option of embedding an "local In-process COM server" into the application, not a "remote COM EXE server". I tried everything I know, so far with no results.. Please help, Rubi :doh:
-
Making MFC Doc/view COM EXEHi ! Is it possible to take an existing MFC application and to manually add code such, that the application becomes a COM exe server ? I found something about such a "supported addition" --> "How to Add ATL Support to an MFC EXE" http://support.microsoft.com/default.aspx?scid=kb;EN-US;175190 but it doesn't seem to work. I think that that example does't deal with COM EXE but just with plain COM. Can anybody shed a light on this subject ? Thanks Roland Rubichi
-
Making MFC Doc/view COM EXEHi ! Is it possible to take an existing MFC application and to manually add code such, that the application becomes a COM exe server ? I found something about such a "supported addition" --> "How to Add ATL Support to an MFC EXE" http://support.microsoft.com/default.aspx?scid=kb;EN-US;175190, but it doesn't seem to work. I think that that example does't deal with COM EXE but just with plain COM. Can anybody shed a light on this subject ? Thanks Roland Rubichi