Please could you clarify exactly what you are requesting. i.e. Are you looking to receieve messages on your client? Is this the same client as the previous client? If the client is the same program, then the usual way to allow the server to call the client by using an event sink, which you can search for and read about on CodeProject, and most books on COM. This generally works very well, but the security issues can be a real pain to overcome. I cannot say any more than this at this stage without knowing more details.

How many applications do you have that need to send output to the server GUI? If the answer is just one or two, then you could just write a short function to create the COM interface object on the remote server, use it, and then release the interface. The downside of doing this would be that several round trips between the client and server computers would be necessary, resulting in time delays, plus you would need to deal with the security issues in all the client programs, and of course the server. What sort of scale are we discussing here? How many messages would need to be sent. Would you need to keep the interface open during the total life of the client program, or could it open just when sending messages to the server? If you wanted to recreate the com interface every time that you wish to send a message, you could write some code like this (using MFC CStrings, but these could be replaced with other types): int PrintToServerGUI( LPCTSTR szFormat, ... ) { int nTextLen = 0; if ( szFormat ) { CString strOut; va_list p_arg; va_start( p_arg, szFormat ); strOut.FormatV( szFormat, p_arg ); nTextLen = strOut.GetLength(); va_end( p_arg ); } int nWritten = 0; if ( nTextLen > 0 ) { // Create interface to my server GUI IMyServerGUI *pMyServer = NULL; ... // Code for creating interface using CoCreateInstanceEx() eg ... // hr = CoCreateInstanceEx(CLSID_MyServer, NULL, CLSCTX_REMOTE_SERVER, &csi, 1, qi ); ... // pMyServer = static_cast<IMyServerGUI *>(qi[0].pItf); ... if ( pMyServer ) { if ( SUCCEEDED( pMyServer->OutputString( strOut ) ) ) { nWritten = nTextLen; } pMyServer->Release(); } } return nTextLen; } You need to write your own interface creation code for your com interface. Note that is code assumes that you have a function in your interface called OutputString( LPCTSTR pString ). If there are a lot of applications that need to communicate with the server, then it may be better to use an intermediate server programming on the local client, that would then pass the messages as appropriate to the server program. The advantage would be that in network security terms, you would only need to concern yourself with the traffic between the server and intermediate server.

The most important thing to check is the InitInstance of the server app. The function _Module.RegisterClassObjects() is called to setup the class factory. For the multiple user situation that you need it is important that the parameter REGCLS_SINGLEUSE is not used. Make sure that a line similar to this is applied: _Module.RegisterClassObjects(CLSCTX_LOCAL_SERVER, REGCLS_MULTIPLEUSE ) (NB In vc7.1, the object might be _AtlModule) Make sure that the server is running before you use the client. Assuming that that messages can be posted to your edit box from anywhere in your server app, you can send a message from the constructor of your interface class to show that the interface has been created from the running instance of your server. If this does not work, or is not applicable then please let me know.

I cannot give you an example, but I can tell you how to set one up for yourself, assuming that you have some knowledge of COM. If you have any problems with these suggestions, that you will need to consult the help documentation, or post a simple question. Before I start, I would like to say that operation of DCOM is much the same as the operation of COM. If you get the server and clients to work together on the same computer, then all you need to do is to change a few calls, and make sure that the security privileges are set, and then everything should work. Unfortunately, security is not a trivial matter, and you will probably have to study it for yourself, in order to get everything working. Firstly create a com out-of-process exe server, with your desired remote interface included. Secondly create a client application that is able to use the above created server interface on your local computer. Use CoCreateInstanceEx() to create the instance of the interface, setting the "ServerComputerName" to your local computer name eg: COSERVERINFO csi = {0}; csi.pwszName = L"ServerComputerName" csi.pAuthInfo = NULL; MULTI_QI qi[1] = {0}; qi[0].pIID = &IID_IMyInterface if ( SUCCEEDED( CoCreateInstanceEx(CLSID_MyInterface, NULL, CLSCTX_REMOTE_SERVER, &csi, 1, qi ) ) { CMyInterface *pMyInterface = static_cast( qi[0].pItf); // Use the created pMyInterface and release it if no longer needed } Test it to make sure your server interface works as anticipated. When it does, you can replace ServerComputerName with the actual intended server. Security is the number one headache when programming DCOM. Inserte calls to CoInitializeSecurity() in the server and client InitInstance() like this: CoInitializeSecurity(NULL, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_NONE,RPC_C_IMP_LEVEL_IMPERSONATE, NULL, EOAC_NONE, NULL); which will reduce the security checking. Install the server onto another computer by registering it and running it. Use DCOMCNFG to check that permissions have been set so that remote users have access to your server program. You may also need to set the COM default limits. You should be able read up on using DCOMCNFG in any good COM documentation. Finally on XP etc, check that the firewall will allow this program to allow/have access to remote users. You may also need to set the firewall on the client computer to allow your computer program to connect out. If all the steps have been followed successfully, then you shoul

If anyone is interested, I have now been able to resolve all my problems. Once I had denied launch permission to everyone, and also reste the security info the OleView, everything worked fine, and continues to work perfectly. This one took me a long to find, despite being in and out of the dcomcnfg program checking the permissions. I hope that this response will be able to help without anyone else that has similar problems.

Although I have been using COM for some time now, I am trying to do something something different from my usual experience and I have run into a problem that I am unable to solve at the moment, and would be grateful for any assistance. My intention is to have a singleton EXE COM server running on a LAN connected computer. This server will be started once, and then remote users can connected to it. I am running currently as the interactive user, but may change this to a service at a later date. If the remote and local computers are both logged in as the same user, then everything works fine as expected. However, if a different user runs the client, and tries to access the running version on the server then there is no response, and instead another instance of the server program is started despite supposed to being a singleton. Please could anyone account for the difference between in behaviour? I have tried many different security configurations including administrator, but have been unable to overcome this problem. The security initialization code reads CoInitializeSecurity(NULL, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_NONE, RPC_C_IMP_LEVEL_IMPERSONATE, NULL, EOAC_NONE, NULL); which usually overcomes every problem for me. Thanking anyone in advance who gives this some attention.

Although I do not know what is in the imported test.tlb, the error message means that the interface ITestSrv has not been defined. I would check where ITestSrv exists and is defined, and make sure that your header file can see the definition.

I would be grateful for help on this problem. I have a DCOM application running on a client computer, which is started by a process on a server computer. It is important that this application only runs on the clients. The DCOM application is started by calling CoCreateInstanceEx() and an event sink is started using DispEventAdvise(). This works 100% once DCOMCNFG is used to set the launch and access permissions. On a terminal services setup, the clients run all the processes on a server computer, except for this one DCOM app. When starting the process, the DCOM app starts as expected on the client computer, but when starting the sink, DispEventAdvise() returns 0x80070005 or E_ACCESSDENIED. I cannot find what security setting that I might need to drop in order to remove this problem and I have been pulling my hair out on this matter for some time.:(( Any assistance would be warmly received.

Near the bottom of the .rc file, you will see a line like this: 1 TYPELIB "myproject.tlb" If you comment out this line, then the type libary will not be included (assuming that APSTUDIO_INVOKED has not been defined). If APSTUDIO_INVOKED has been defined, then you will need to comment out the TEXTINCLUDE section higher up in the .rc file which contain a similar TYPELIB line.

The type library in the resources is just included for convenience so that other programmers can view the COM interfaces etc. but does not directly affect the actual interfaces implemented. If you remove this information from the DLLs resource (comment out the lines in the .rc file), the actual interfaces will still function normally.

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.

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 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.

Firstly, I would offer the same advice, don't write your own linked lists or collections etc, use STL or the MFC CList etc. The problem in your code appears to be a confusion in the pointers, and the code is littered with such problems, eg in AddToQueue(), you have set temp to be of type struct questlist **, but your call to malloc (btw why are you not using new???), will create a pointer to a single queuelist (i.e. (struct queuelist *)). So you should change the code to something like struct queuelist *temp = NULL; ............. temp = (struct queuelist *)malloc( sizeof(struct queuelist) ); if ( temp == NULL ) { // Not enough memory etc } else { temp->intData = data; temp->next=NULL; temp->valid=1; *q = temp; } The function call to AddToQueue() in your main part should read AddToQueue( &queue ) else the wrong type is being passed to the function. I must admit that I am surprised that your compiler did not generate warning messages with your code? I think that you would be best of revisiting all of your code, and checking all your pointers and paraeters. Remember that malloc will only return a pointer to a section of memory that you have allocated. Better still, use STL or perhaps the MFC CList template.

Fixed by these changes: A) Added a Test method to the event sink which is empty at the client method B) When the server tries to close itself, it calls the above Test method. If an RPC error results, it is assumed that the client has broken. C) Server shutdown is firstly achieved by calling CFrameWnd::OnClose() (as an MFC frame window). If the client has been broken, then AfxPostQuitMessage(0) is called immediately afterwards to terminate the process. Effectively the call to AfxPostQuitMessage does an AfxOleUnlockApp() so that the server can quit gracefully. I discovered this by debugging the MFC code. The only bad thing about this approach was the need to add another event method to the sink, and to hardwire a call to this in the server. Does anyone have a better approach to this?

I have an out-of-process exe server which was a one-to-one connection with a client. The client will start the exe server when using CoCreateInstance() in the usual way, generating an IMyInterface pointer. In normal execution, when the client process closes, Release() is called for the IMyInterface pointer, which terminates the server. Unfortunately, there are some instabilities in the client executable over which I have no control. If the client crashes, which it does particularly during testing, then the normal IMyInterface Release() is not called, and thus the server does not get released and stays executing. What I would like to be able to do is to test whether the client is still running. My problem is that the wizard-generated event sink code does not return an E_FAIL or similar error code, if the connection fails. I know that there are several ways in which I could address this problem, each with their own disadvantages. I would really appreciate if anyone could offer any help on this, of advise me whether I am missing something obvious. FB

I recently used the interface that I found in this article http://www.codeproject.com/useritems/email.asp?target=MAPI[^] Some of the code is perhaps a bit rusty, and may not be fully implemented, but working with the example code made it easy for me to understand the mechanisms involved, and it was straightforward to sort out any problems and adapt the COM interface for my own needs. I was extremely grateful for the help provided by this article.

Sometimes, it is necessary to change a floating point number to an integer. The usual way of doing this is just to write i = (int)f; However, the C++ compiler also lets one express this desire like this: i = int( f ); which is how functions are normally written, and it is easier to understand in complicated expressions rather than casts. Similar expressions can be produced with other implicit types eg double and float eg dbl = double( i ); Does anyone know when it became possible to write the code like this, as opposed to using casts? Does anyone know if there are any drawbacks or using this approach? All comments are welcome:)

In order to attach to Excel, you will have called CreateDispatch() and/or AttachDispatch(). There is a corresponding function ReleaseDispatch() which you can call when you do not need the interface open any longer. Alternatively, you could use the second parameter of void AttachDispatch( LPDISPATCH lpDispatch, BOOL bAutoRelease = TRUE ) to autorelease the interface for you. Note that Excel, or any other automaton, will not close until all the attached interfaces have been released.

I am also not familiar with Reflection. However if all you want to do is to produce a new class object based on the string passed into a function, one of the factory methods would work fine. For achieving your simple aim, the Builder method or the Abstract Factory should suffice. I believe that there are various cool methods already on CodeProject on these subjects.