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.

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?

FearlessBurner wrote: _i = (int)f;_ Is a cast. FearlessBurner wrote: _i = int( f );_ Constructs an unnamed (temporary) int, using f as the initialiser value, and assigns/copies the value to i. Your compiler probably optimises this. FearlessBurner wrote: _dbl = double( i );_ Is similar to the previous comment, and constructs a temporary unnamed double. FearlessBurner wrote: 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? It probably became possible to write this when you changed from C to C++. My own recommendation is to cast using the C++ casts, instead of the C casts, so for the example above I'd write: i = static_cast<int> (f); Because it's easier to find casts that use the C++ syntax for casts over the C syntax, and using the correct C++ cast can reduce or highlight potential errors caused by casting - this particularly applies to the other three C++ casts (const_cast, dynamic_cast, and reinterpret_cast) -- Ian Darling "The moral of the story is that with a contrived example, you can prove anything." - Joel Spolsky

Thanks to Kuphryn and Steve for both the replys. I intend to zip/unzip the string as suggested in order to save transmission time, and am incorporating some of the info from some of the helpful articles in CodeProject. I would also like to consider TCP/IP as a solution but that will be some steep learning so I will delay that for now. Thanks again.

Thanks for the comment Vita.:) I wasn't completely sure without trying it whether I would be able to use BindToObject() to attach to the process but I won't even try now. Anyway, I have reflectioning further on this, and guess that what I am trying to do is not strictly necessary and can hopefully achieve what I need using a slightly different approach. If I use the pIMyApp->CreateDispatch( "InterfaceName" ) function to get the interfaces that I need then that should suffice, as long as the required interfaces all connect to just one singleton instance of my exe automation server. As per normal apps, the important thing is the data, which must be common so that the interfaces can access it. I am, of course, greatful for any help that I might receive.