System Tray Application

  • Thread starter Thread starter Jay
  • Start date Start date
J

Jay

Hey There,
I have a system tray application that is running, and it needs to
communicate with a Windows Service that I wrote. My problem is that if
a user switches to another desktop, I need the service to have
communication be able to distinguish that data needs to be sent to app
A instead of app B. I was going to try to use a desktop handle to
distinguish between the two, but I can't create the service as an
interactive service (nor would I want to, with it being a security
flaw, and also with Windows explicitly not allowing it in Vista). So,
if I have data that needs to be sent to one system tray app, how can I
differentiate between the two?

Thanks!
Jay
(patelj27b at gmail dot com)
 
Jay said:
I have a system tray application that is running, and it needs to
communicate with a Windows Service that I wrote. My problem is that if
a user switches to another desktop, I need the service to have
communication be able to distinguish that data needs to be sent to app
A instead of app B. I was going to try to use a desktop handle to
distinguish between the two, but I can't create the service as an
interactive service (nor would I want to, with it being a security
flaw, and also with Windows explicitly not allowing it in Vista). So,
if I have data that needs to be sent to one system tray app, how can I
differentiate between the two?
Click to expand...

I'm not sure what the problem is. Can't you have the service expose a socket
or a named-pipe interface to its clients? You can tag the messages that you
send over the socket or pipe with whatever identifying information you need.

Regards,
Will
 
William said:
I'm not sure what the problem is. Can't you have the service expose a socket
or a named-pipe interface to its clients? You can tag the messages that you
send over the socket or pipe with whatever identifying information you need.

Regards,
Will
Click to expand...

If the service needs to do some desktop interaction through the system
tray application, then it needs to know which one to do it on. the
originating message doesn't have information regarding which system
tray application to send it to. That conjunction information will be
kept in custom structures.

Thanks!
Jay
(patelj27b at gmail dot com)
 
Jay said:
If the service needs to do some desktop interaction through the system
tray application, then it needs to know which one to do it on.
Click to expand...

Services should not interact with the desktop. That's the issue. AFAIK,
Vista will no longer support interactive services. IMO, now is a good time
to change your design.

Regards,
Will
 
Jay said:
Hey There,
I have a system tray application that is running, and it needs to
communicate with a Windows Service that I wrote. My problem is that if
a user switches to another desktop, I need the service to have
communication be able to distinguish that data needs to be sent to app
A instead of app B. I was going to try to use a desktop handle to
distinguish between the two, but I can't create the service as an
interactive service (nor would I want to, with it being a security
flaw, and also with Windows explicitly not allowing it in Vista). So,
if I have data that needs to be sent to one system tray app, how can I
differentiate between the two?
Click to expand...

I think you're missing Will's point. You server should expose an RPC
interface - through sockets, named pipes, etc. Your system tray application
should connect to your server through that API when it's started and
disconnect from your server when the desktop is shut down (user logs out).
If multiple desktops are active (e.g. fast user switching, terminal
services), then you will have multiple copies of your client application
running and your server can send information to all of them, or use any
information at it's disposal to decide which client to send to.

Ultimately, the client is in a better position to decide whether it's
appropriate for it to receive information, since it has direct access to
it's own desktop and can easily discover when that desktop becomes inactive
or is destroyed. The server should simply do what it's told - returning
information to whichever client(s) ask for it.

Remember - think in terms of the client ASKing for information, not the
server SENDing information.

-cd
 
William DePalo said:
Services should not interact with the desktop. That's the issue. AFAIK,
Vista will no longer support interactive services. IMO, now is a good time
to change your design.
Click to expand...

I believe "through the system tray application" running in the logged-in
user's context, IS the right way. It's only services that try to create UI
windows within the service process that need to be changed. Or no?
 
Ben Voigt said:
I believe "through the system tray application" running in the logged-in
user's context, IS the right way.
Click to expand...

Yes, of course.

There's not a lot special about a tray application apart from the fact that
it is the shell displaying an icon in its client area for some other quite
ordinary application. Ordinary appplications are free to paint their UIs as
they like.
It's only services that try to create UI windows within the service
process that need to be changed. Or no?
Click to expand...

Yes. Which is why I told the OP not to have his service interact with the
desktop (Vista will burn him in a couple of months).

The canonical approach is to have the service interact via some IPC
mechanism -with a non-service application which interacts with the desktop.

Regards,
Will
 
Carl said:
I think you're missing Will's point. You server should expose an RPC
interface - through sockets, named pipes, etc. Your system tray application
should connect to your server through that API when it's started and
disconnect from your server when the desktop is shut down (user logs out).
If multiple desktops are active (e.g. fast user switching, terminal
services), then you will have multiple copies of your client application
running and your server can send information to all of them, or use any
information at it's disposal to decide which client to send to.

Ultimately, the client is in a better position to decide whether it's
appropriate for it to receive information, since it has direct access to
it's own desktop and can easily discover when that desktop becomes inactive
or is destroyed. The server should simply do what it's told - returning
information to whichever client(s) ask for it.

Remember - think in terms of the client ASKing for information, not the
server SENDing information.

-cd
Click to expand...

Thanks for all your help,
The situation above is what I have. I don't want to just blindly
send the message to all copies of the application. The service should
be able to know which one it is meant for and send it to that one. And
I am using sockets to send and receive data between the service and the
helper application. The purpose of the helper application is to do
whatever desktop interactions the service needs done.

-Jay
(patelj27b at gmail dot com)
 
It's only services that try to create UI windows within the service
Yes. Which is why I told the OP not to have his service interact with the
desktop (Vista will burn him in a couple of months).

The canonical approach is to have the service interact via some IPC
mechanism -with a non-service application which interacts with the
desktop.
Click to expand...

But you're preaching to the choir (the OP started out "I have a system tray
application that is running, and it needs to communicate with a Windows
Service that I wrote") and confusing the issue at the same time. Of course
a service should interact with a user, there are a variety of ways of doing
that, with varying levels of security. Having the service create a UI
window in-process is bad. Having the service delegate that UI window to a
separate app running in the user's security context, can be good, but
security checks are still needed, whether via named pipe ACLs, or
application-layer checks. Now the OP has run into the problem that there
can be multiple instances of this "separate app running in the user's
security context", whether via Remote Desktop/Fast User Switching (only one
user) or Terminal Services (concurrent users) and is looking for a way to
decide which instance to send prompts and notifications.
 
Thanks for all your help,
The situation above is what I have. I don't want to just blindly
send the message to all copies of the application. The service should
be able to know which one it is meant for and send it to that one. And
I am using sockets to send and receive data between the service and the
helper application. The purpose of the helper application is to do
whatever desktop interactions the service needs done.
Click to expand...

Is the message a response to a helper application request, or a notification
triggered by something else in the system (disk attached, virus found, etc)?
 
Ben Voigt said:
Now the OP has run into the problem that there can be multiple instances
of this "separate app running in the user's security context", whether via
Remote Desktop/Fast User Switching (only one user) or Terminal Services
(concurrent users) and is looking for a way to decide which instance to
send prompts and notifications.
Click to expand...

So? The pipes and sockets that I suggested work well in a many-to-one
environment.

It's client server 101. He can have each client register the location or
means of a call back with the service. At the proper time the service
"calls" or "messages" the client. The client does the UI. Voila.

I think his issue (and I could be wrong as he didn't offer a lot in the way
of detail) - is that his service is making a (perhaps implicit) assumption
that client and service are on the same desktop. If not, why would the
user's desktop switching be a problem for him?

The Shatter Attack is a big enough deal and Vista's change is significant
enough that, IMO though YMMV, that it is worth pointing out to the OP and
anyone else reading my post that a service should not run on an interactive
desktop.

Regards,
Will
 
Ben said:
Is the message a response to a helper application request, or a notification
triggered by something else in the system (disk attached, virus found, etc)?
Click to expand...

Actually, some other application will send a message to the service,
and the service will need to send the information to the proper helper
application running. The service has interaction with other
applications which will sometimes need to direct information to the
helper application. It isn't just a one-to-one interaction. If I were
to have an array of sockets, each one connected to a specific helper
application, I would need to know that when a certain message is
received from another application, it needs to be directed to a
specific helper application.

-Jay
 
Back
Top