Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Starting a New GUI Application from a service?

Status
Not open for further replies.

Insider1984

Technical User
Feb 15, 2002
132
US
Hi I have a service that is actively listening for a certain signal and on that signal will launch a regular C# .Net 2.0 Windows Application. I'm using the following code:


Process fwi = new Process();
fwi.StartInfo.FileName = "D:\\MYAPP.exe";
fwi.StartInfo.Arguments = "-a";
fwi.StartInfo.CreateNoWindow = false;
fwi.StartInfo.UseShellExecute = true;
fwi.Start();

The service after the last line will sit in wait mode again and (after putting some sleeps into the code) I was able to attach myself to MYAPP.exe and determine a few things:

1. MessageBoxes anywhere inside the Form's initialization will not work with a weird error:

"Showing a form when the application is not running in
UserInteractive mode is not a valid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service application."

So I got rid of them (they were for debugging anyway).... but then the form just never comes up but the application keeps running.

If I launch the application with or without arguments from it's own exe, from cmd etc it works just fine!

Any ideas? The service doesn't need any feedback from the application. It is almost like the Process is being generated under the service's "runtime". I know that my word usage isn't right but hopefully the point is across...

=====================
Insider
4 year 'on the fly' programmer
C, C++, C#, MFC, Basic, Java ASP.NET
 
Here we go again.

The only thing I can say is "Stop That!"

A service is not meant to have GUI interaction. It runs as the System user so when you display gui - it shows up only in the System user space - not the logged in user.

And what happens if nobody is logged in?

The best way around this is to create an application that runs in the background as soon as the user logs in. Each user will have their own instance of this application running. You could put the app in the startup folder or create a custom startup script for windows.

This is my best suggestion.
 
I guess I should mention that this is a specific setup for a manufacturing machine. The machines have auto login and the sole purpose of this setup is that multiple PC's are being given a command to startup an application. It has a gui but doesn't really have much user interaction while in this mode. It really just does work and reports to a database when complete.

So I understand that in the world of a windows friendly multiple app world, this is not the way to do things..... that being said, we are running windows simply because .Net 2.0 was the most powerful and fastest way to code up what we needed.

=====================
Insider
4 year 'on the fly' programmer
C, C++, C#, MFC, Basic, Java ASP.NET
 
So where is the issue in starting this application as a simple WindowsApplication after the auto-login?
 
I would structure it thusly:

1. Create a "listener" application that runs from the startup folder.

2. Create a "notifier" application that runs on a supervisory PC.

3. The listener connects to a MSMQ queue, or opens a TCP/IP socket, or monitors a database table, (etc. etc). for an indication to start the real task.

3. It then launches the real task, and optionally returns status to the supervisor.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
 
Thanks, I ended up doing that last week after not getting any responses. My problem with the application is that it needed to be a background app that would always be running so unfortunately I spent some additional time placing a tray icon, over riding the closing events etc. Good news is that in addition to logging to the event log I also now had a nice little fixed size list box to display what the app is doing so that is a bit useful.

All the communication is build using a previously developed TCP/IP packet class built pretty much as a command/parameters setup.

There is of course still a risk that someone can quit the application (though it would almost need to be on purpose).



=====================
Insider
4 year 'on the fly' programmer
C, C++, C#, MFC, Basic, Java ASP.NET
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top