We have the following situation:
An ATL COM server (out-of-proc, EXE) which hosts COM objects with connection points. These objects "live inside" a single (exe) process and they fire events (using the Fire_* methods) so that other processes (for example: a .NET GUI application in a different process, the "client" of the ATL EXE server) can catch these events and react accordingly.
Currently, we have a .NET application (Windows Forms) which is the client of the ATL server. When started (double clicked) it attaches some delegates (event handlers) to the COM objects events (connection points) hosted in the ATL server. Each time an event is fired from the ATL server, the .NET client usually displays some info in the main Window or opens a new Window for the user to interact with. This solution is based on the following article: http://www.codeproject.com/KB/COM/cominterop.aspx#ConnectionPoints (COM-.NET event handling).
The above scenario assumes that the user had actually double-clicked the .NET client (exe) prior to the firing of the events, that is - Opened the .NET application explicitly. In case the .NET client is not opened (instantiated) the fired event is "lost" - no client handled it.
We want the following situation:
When an event is fired from the ATL server, a Window should immediately appear (pop-up) for the user to interact with (for example: fill an email text box & press "Ok"), without the need to start the .NET client explicitly prior to everything. This way, the user will be notified about each event and can interactively react to it.
We looked at the option to host the .NET client app as a dll inside the ATL server, but I've read that displaying GUI from an ATL EXE is a big "NO-NO" (any GUI, not just .NET GUI like WinForms or WPF).
Is this possible when the server & client run in two different processes (and the "client" is not yet running)? Did anyone run into the same problem? was it solved (and how...)?
Thanks ;-)
Omri
Is there a solution for this?
You can't make this work the way you describe. If there is nobody listening to the event then there is no way to respond to it. Trivially solve your problem by starting the .NET app with a shortcut in the Startup folder so it always runs while a user is logged-in. You don't have to create a window until you get the notification from the server. Stealing the focus away isn't going to work btw so you'll probably want a NotifyIcon with a balloon.