The question is way too vague to give the exact advice. You did not describe your existing architecture and what have you tried. You did not explain what could be your problem.
But the idea could be this: you should remember that your windows service works even if there is no a desktop, so none of the UI applications even exist. So, the collaboration you need should be established by the initiative of your UI application, which is inline with the concept of "client-server".
You have to create some network or, more appropriately, IPC service in your windows service. It could be done directly using sockets or named pipes, or, on a higher level, using "classic" remoting or WCF hosted in your windows service. The UI application should be able to connect to the service (presumably, on their startop and disconnect before their termination) and subscribe to some service events (whatever you need to introduce). In the handlers of those events, the UI application can change the states of the buttons or whatever you need to change. The server should remain agnostic of the UI behavior. This way, you would support
loose coupling and avoid
strong coupling, which is very important in this case.
Please see also:
http://en.wikipedia.org/wiki/Loose_coupling[
^],
http://en.wikipedia.org/wiki/Coupling_(computer_science)[
^].
—SA
Submit an article or tip