ATL support to existing MFC application
-
Hi 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:
-
Hi 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:
I can assure you that it is possible, as I have been forced to do the same myself in the past. How I approached the problem was to build test out-of-process MFC EXE applications from scratch using the MSVC wizards, and contrasted that with a similar standalone EXE application without ATL, and researched each extra line added by the wizard. I must admit that the MS article that you have found looks to be good, and if I had had found the same article it would have saved me much time. One of the problems that I remember was in coding the clients. For a straight automation enabled MFC SDI application, the client calls the IMyApp.Document interface, which you can access via CreateDispatch() and related function. If you were building a COM EXE server without a document interface, the client interface initialized using CoCreateInstance(). This may be the source of your problem. Feel free to ask more specific question, and I will do my best to remember.
-
Hi 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:
I would also recommend using the OLE/COM Object Viewer to establish whether your interface has been correctly registered. You could write a short VBScript to test your server. If this works, then you would know that you have a problem with your client. In response to your email, please note that I unable to debug your code for you, as I do not have the time and I do not need the acknowledgement. I am willing to help through these postings on this message board just as long as this is a two-way process.
-
I would also recommend using the OLE/COM Object Viewer to establish whether your interface has been correctly registered. You could write a short VBScript to test your server. If this works, then you would know that you have a problem with your client. In response to your email, please note that I unable to debug your code for you, as I do not have the time and I do not need the acknowledgement. I am willing to help through these postings on this message board just as long as this is a two-way process.
-
Hi 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:
First 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
-
First 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
Excellent. :) I am very pleased that you were able to discover the problem yourself and put it up as a response. This should benefit the next programmer who wants to do something similar.