What messages closes a form?

[jhammer]

I need to know what windows messages closes a windows form (WM_QUIT, WM_CLOSE, other)?
If I kill the process (say using the Task Manager or Process.Kill), what message closes the form then? Can I catch it in WndProc method?

[MadHatter]

wm_close is sent before wm_destroy. I believe wm_syscommand also has a close parameter sc_close (depending on who invoked close).

if you kill the process, no messages are sent to destroy the window, the process is killed and memory allocated to the app are reclaimed. its possible to determine if your process is about to be killed, but I dont know that that is available in C#'s object model.

[darwen]

Killing the process in TaskManager involves these messages :

(1) A WM_CLOSE message is sent to the main window. If that doesn't respond then...
(2) You get the 'Waiting to close' message. After a certain length of time then the OS shuts down the application by killing the process directly, as well as terminating all threads associated with the process.

(2) Normally involves having memory leaks in native code.

However in managed code, there should be no memory leaks in abnormally shutting down your application.

Darwen.

[MadHatter]

killing a process invokes TerminateProcess which kills all threads imediately (only waits for a response from IO operations as far as I know). any pending messages in the queue (whether wm_close is waiting for processing or not) are terminated with the message loop, which is why doing so keeps wm_close from being sent to a windows message queue.

[jhammer]

Now I am confused. What way can I know in C# that the process was terminated abnormally? Is catching the WM_CLOSE, WM_DESTROY etc enough?

If what Madhatter is writing is correct, so how can I know when this TerminateProcess message is sent?

[darwen]

True, you can use this method.

Nice applications (i.e. professional applications) do not use this method.

Professional applications send a WM_CLOSE to the main window of the application.

However, with .NET who knows ? Good practice has been thrown to the wind because of the GC which takes care of all of this for you.

Don't get me wrong, I love .NET. But there are so many bad programmers out there (i.e. people who use .NET because of the 'no memory leak' situation) who can say ?

Darwen.

[SouthernCodeMonkey]

If what Madhatter is writing is correct, so how can I know when this TerminateProcess message is sent?

You can know when TerminateProcess is being invoked against your process by externally hooking the form through a DLL coupled with API hooking. C# directly facilitates providing a native WndProc for just this reason (which is done routinely in professional applications).

Regards.

[MadHatter]

if you're just wanting to know if your app is closing (not being killed) attach to the Closing event in your main form, you can also attach to the Application's ThreadExit event if the app terminates due to unnatural cause (unhandled exceptions). you dont *have* to watch the message queue. now watching for an app being *killed* is another story all together.

"Professional applications" have the same problem that "anyone" has to deal with. close / destroy messages are not sent to any app if it is killed externally.

killing a process outside of that process is a function of the operating system and not the language or framework it is written in. any "executable" written in any language executes in a layer provided by the operating system and ExitProcess and TerminateProcess is a function of the Operating System whether they're windowing or not.

open up Microsoft office. open spy and place it on the top level window. open up task manager and kill it. do you see anything? no, and you wont. this is because when kill is invoked, it does not know nor care what it is killing. the OS knows what it has and how to reclaim it (most of the time anyway). these rules apply no matter what its written in because they all are subject to the way the lower level OS deals with allocating and deallocating resources. the platfrom docs talk about how doing this can cause problems because it cleans house regardless of who's data its deleting (in the case of global stores). it doesnt know to invoke a "clean up" routine on a process its killing. if it did, then i'm sure it would be able to gracefully shut the process/application down (send a close message). but it cant and wont.

there are 2 common methods employed. one is to use a semiphore file (notice that when you start a Word document, it creates a second file that caches info it needs to recover) which you could implement a similar thing to cache the data while your object is "dirty". the other way is to hook into the running app from another process as SouthernCodeMonkey said. one is simply for recovery of the last operation, and the second is more of a preventitive measure.

(also on a side note) you still have memory leaks in .NET. not everything is managed and not everything is placed in the managed set (a great portion of .NET is a wrapper to other unmanaged things anyway). The GC doesnt manage every aspect of what goes on in the framework. reflection for instance places all of its method info cache in unmanaged memory so if you're doing a lot of dynamic work through the method invoker you'll leak quite a bit. also using graphics in .net is overly prone to leaks. most things are managed in .net but the great thing about it is that they still give you enough rope to hang yourself with if you dont know what you're doing