I reading the documentation, it seems unlikely that a service can directly
pass information to an application.
However, a service can broadcast messages like any other running process, and that might be a way to send information to an application.
Additionally, ugly as it is, a service should be able to write to the disk, and you can instruct your application to monitor a specific location on the disk for the arrival of a file. (Ugly, I know.)
There might be a way to implement cross-process marshalling, but the way to do that does not immediately "leap off the page."
Perhaps you could override ExecuteCommand() with Public Sub ExecuteCommand([u]B</u>y[u]Ref</u>
command As Integer), and then modify command in the processes that ensued, but I am skeptical that that would work.
I am not confident of my answer here, Iâm only sharing what my perspective is on the possibility. This assertion in Visual Studio .NET help is what makes me doubt that [u]direct</u> interaction (even as [u]in
</u>direct as your particular approach is) with a user (ie, another application) will be possible:
quote:Windows Service applications run in a different window station than the interactive station of the logged-on user.1 Because the station of the Windows Service is not an interactive station, dialogs raised from within a Windows Service app. will not be seen and may cause your program to stop responding. . . .
The Windows Service classes supported by the .NET Framework do not support interaction with interactive stations, that is, the logged-on user [Iâm presuming that this includes any apps the logged-on user runs]. The .NET Framework also does not include classes that represent stations and desktops. If your Windows Service must interact with other stations, you will need to access the unmanaged Windows API. For more info., see Window Stations and Desktops in the Platform SDK documentation.
1. A window station is a secure object that contains a clipboard, a set of global atoms, and a group of desktop objects.