Re: Relationship between Application.Exit() and AppDomain

"Barry Kelly" <barry.j.kelly@xxxxxxxxx> wrote in message news:n0ldv3ldnahq7cs5gubq2qqi3fp3fs99aq@xxxxxxxxxx
Willy Denoyette [MVP] wrote:

Application.Exit() is a Forms API,

That is true.

so A.E makes no sense in WPF.

That may be strictly true, but try this on for size:

---8<---
using System;
using System.Windows;
using System.Threading;
using System.Runtime.InteropServices;
using System.Windows.Controls;

public class App
{
[DllImport("user32.dll")]
static extern void PostQuitMessage(int nExitCode);

static Button MakeQuitButton()
{
Button result = new Button();
result.Content = "Quit";
result.Click += (s,e) => PostQuitMessage(0);
return result;
}

[STAThread]
static void Main()
{
new Application().Run(new Window()
{
Content = MakeQuitButton()
});
}
}
--->8---


Well here you are calling PostQuitMessage which doesn't really do what it's supposed to do, also System.Windows.Forms.Application.Exit doesn't do what it has to do here (in a WPF based app.). Take a look at the messages using Spyxx.exe, you'll see that none of the API's are sending WM_QUIT message to your application. A.E does not terminate the UI thread whereas PostQuitMessage simply terminates the UI thread and as such the application.
If you are looking for the equivalent of A.E in WPF, then take a look at Application.Shutdown, PostQuitMessage shouldn't be used at all.

WPF does not run a message loop

This is empirically false:


Well, above is quite confusing, I should have been more explicit.
Every Windows Application, no matter what the UI framework used , will have at least one top level window, this is also true for WPF based application. A minimal WPF application has at least one single Window (HWND) that is used as a *host* or wrap WPF.
This top level Window, with it's associated message loop and WndProc, receives/handles all Windows messages for the application, WPF itself is not HWND based, Windows messages are translated (when appropriate) into CLR events that get routed to the the WPF Visuals. This top level HWND isn't exposed and accessible like it is in other frameworks like Windows.Forms, you can't override WndProc for instance,you shouldn't even assume such Window is present. Note also that the WPF core registers Windows messages that aren't know to Windows.Forms and vice-versa, that's why there is an WPF/Forms interop layer in the form of the HwndHost control.

Willy.

.

Loading