just.a.nerd

I have an application without any forms. it's started using an ApplicationContext, so it does have a messageloop (required by a messagewindow).

The application is intended to run in the background, started from registry and closing down on SystemEvents.SessionEnding.

This is all ok.

But now I want to close it manually from another program, using the Process class to get the process and then close it.

Since it doesn't have a form, I can't use Process.CloseMainWindow.

Process.Kill is bad - I need it to close gracefully, like calling Application.Exit() - this is what I do from the SessionEnding event.

Surely others must have done this before, but how What is the elegant solution to this, what do you do




Re: Visual C# General Closing a formless application (gracefully)

nmadd

Hi there,
I can't say that I have a solution, but I can say that this is what MSDN says:

"Kill is the only way to terminate processes that do not have graphical interfaces."

I'll definitely keep an eye on this thread and hope that somebody can find a graceful solution for you. Good luck.




Re: Visual C# General Closing a formless application (gracefully)

Jeremy Filburn

Since you have no user interface in your application, why not make it a service (I know nothing about ApplicationContext, thats why I ask).

One way that I can think of to do this is by using FileSystemWatcher class. If your ApplicationContext can use this class to monitor a file, you can use your other application to send a message through the file.

Event Handler

Events Handled

Performs

OnChanged

Changed, Created, Deleted

Report changes in file attributes, created files, and deleted files.

OnRenamed

Renamed

List the old and new paths of renamed files and folders, expanding recursively if needed.






Re: Visual C# General Closing a formless application (gracefully)

Thomas Danecker

If you're using a service, you can just use a ServiceController on your client send a stop-event to the service. The FileSystemWatcher is just an ugly work-around. For sending events to the server, .net Remoting would be much nicer.




Re: Visual C# General Closing a formless application (gracefully)

Peter Ritchie

What object type are you passing to Application.Run




Re: Visual C# General Closing a formless application (gracefully)

sirjis

Normally the most graceful way to end an application is to exit the Main method and all threads. To exit threads, you could use either a boolean flag, a WaitHandle (like AutoResetEvent), or call Abort on the thread (the least graceful of the three).



Re: Visual C# General Closing a formless application (gracefully)

just.a.nerd

To Jeremy and Thomas: I don't use a service because I need messages. As mentioned, I have a messagewindow derived from NativeWindow. However, to find that window from outside is very non-dotnet.

To Peter: I said: " it's started using an ApplicationContext", meaning I use: Application.Run(MyApplicationContext);

The ApplicationContext creates a component, that contains all the program logic. This is a totally normal messagepumping windows application, just without a form!

(All the examples, I have seen regarding ApplicationContext, actually uses forms, so they don't have this problem)

To sirjis: The problem is not to exit the application from inside the application itself. I simply call: Application.Exit();

I subscribe to the Application.Exit event and the eventhandler cleans up.

The real problem is: How can I remotely close the app (in some nice standardized way)

A thought: What does it take to make a window into a mainwindow I mean, native applications also have a mainwindow, which is not a Form. Since I already have a messagewindow, I could change the style or whatever to make it a mainwindow May be some 'old' C programmers could tell me that

That way I could use Process.CloseMainWindow - totally standard way. ... but what is required






Re: Visual C# General Closing a formless application (gracefully)

Jeremy Filburn

I agree with Thomas. It is starting to look like Remoting will be the better way to go.

Maybe you can hook a button when the second app opens






Re: Visual C# General Closing a formless application (gracefully)

just.a.nerd

I was hoping for an elegant solution

After all, the purpose of not having a Form, is to save resources. If I have to make a lot of extra work (and IMO .net remoting is that) then I could just as well use a hidden form and call Process.CloseMainWindow.

Remoting is definately an overkill for sending a simple command to another app.






Re: Visual C# General Closing a formless application (gracefully)

Chris Dunaway

Could you try using p/invoke and calling PostMessage and post a WM_QUIT message to the application

Chris





Re: Visual C# General Closing a formless application (gracefully)

just.a.nerd

Wow, a little p/invoke can do wonders

However, a little change: I use PostThreadMessage (WM_QUIT is not supposed to be posted to a window).

Below is the code I ended up with, it seems to work perfectly, like calling Application.Exit() from inside the application, performing nice cleanup:

Code Snippet

using System;

using System.Windows.Forms;

using System.Diagnostics;

using System.Runtime.InteropServices;

static class Program

{

const uint WM_QUIT = 0x12;

[DllImport("user32.dll", SetLastError = true)]

static extern bool PostThreadMessage(int idThread, uint Msg, IntPtr wParam, IntPtr lParam);

[STAThread]

static void Main()

{

foreach (Process process in Process.GetProcessesByName("MyProgram"))

{

if (process.Id != Process.GetCurrentProcess().Id)

{

try

{

if (process.MainWindowHandle == IntPtr.Zero)

{

foreach (ProcessThread thread in process.Threads)

{

PostThreadMessage(thread.Id, WM_QUIT, IntPtr.Zero, IntPtr.Zero);

}

}

else

{

process.CloseMainWindow();

}

process.WaitForExit(2000);

}

catch

{

}

}

}

}

This will close all instances of the application, whether they have a Form or not, as long as they have a messageloop. It also works for native windows applications, if they perform cleanup when exiting.

Hope others can use this too.

.... and comments are more than welcome, especially if there are any catches to this approach.