Hi Jon,

I modified your example code to create two threads and to start message
loops on each of them as follows:

  static void Main()
   {
       {
           Thread t = new Thread(ShowUI1);
           t.SetApartmentState(ApartmentState.STA);
           t.Start();

           Thread t2 = new Thread(ShowUI2);
           t2.SetApartmentState(ApartmentState.STA);
           t2.Start();
       }
   }

   static void ShowUI1()
   {
       Form form = new Form
       {
           Size = new Size(200, 200),
           Text = "Form UI1"
       };
       Button b = new Button
       {
           Text = "Die!",
           Location = new Point(5, 5)
       };
       b.Click += (s, e) => { Application.Exit(); };
       form.Controls.Add(b);

       Application.Run(form);
   }

   static void ShowUI2()
   {

       Form form = new Form
       {
           Size = new Size(200, 200),
           Text = "Form UI2"
       };
       Button b = new Button
       {
           Text = "Die!",
           Location = new Point(5, 5)
       };
       b.Click += (s, e) => { Application.Exit(); };
       form.Controls.Add(b);

       Application.Run(form);
   }

If you run this code, you’ll see that when you kill one of the Forms the
other dies too and the application shuts down. Apparently, calling
Application.Exit() on one thread kills the other thread's UI as well. This is
in line with Microsoft documentation saying that Application.Exit() method
‘Informs all message pumps that they must terminate, and then closes all
application windows after the messages have been processed’.

Things seem to be different if you create these two threads in different
AppDomains like so:

public class Test: MarshalByRefObject
{
   static void Main()
   {
       {
           AppDomain ad1 = AppDomain.CreateDomain("AD1");
           Test t1 = (Test)
ad1.CreateInstanceAndUnwrap(Assembly.GetExecutingAssembly().FullName, "Test");
           t1.StartUI1();

           AppDomain ad2 = AppDomain.CreateDomain("AD2");
           Test t2 =
(Test)ad2.CreateInstanceAndUnwrap(Assembly.GetExecutingAssembly().FullName,
"Test");
           t2.StartUI2();

       }
   }

   public void StartUI1()
   {
       Thread t = new Thread(ShowUI1);
       t.SetApartmentState(ApartmentState.STA);
       t.Start();
   }

   public void StartUI2()
   {
       Thread t = new Thread(ShowUI2);
       t.SetApartmentState(ApartmentState.STA);
       t.Start();
   }

   public void ShowUI1()
   {
       Form form = new Form
       {
           Size = new Size(200, 200),
           Text = "Form UI1"
       };
       Button b = new Button
       {
           Text = "Die!",
           Location = new Point(5, 5)
       };
       b.Click += (s, e) => { Application.Exit(); };
       form.Controls.Add(b);

       Application.Run(form);
   }

   public void ShowUI2()
   {

       Form form = new Form
       {
           Size = new Size(200, 200),
           Text = "Form UI2"
       };
       Button b = new Button
       {
           Text = "Die!",
           Location = new Point(5, 5)
       };
       b.Click += (s, e) => { Application.Exit(); };
       form.Controls.Add(b);

       Application.Run(form);
   }
}

In this case killing one of the Forms doesn’t kill the other one and this is
not in line with the documentation.

That’s, essentially, what my question was about.

Thanks for replying, it’s nice to hear from you again:)

SS

Jon,

I’ve just done some more tests. My understanding of Willy Denoyette’s
explanation (see at the bottom of this thread) was that Application.Exit()
kills the message pumps in the current Appdomain and its ‘child’ AppDomains.

To verify this I further modified the code with AppDomains so that one of
the threads creates yet another ‘child’ AppDomain and starts yet another
message loop in it. This test showed that my understanding was incorrect. All
three message loops in those AppDomains are independent in the sense that
killing one of them doesn’t kill the others.

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.

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.

Willy,

Thanks very much for a quick reply. Can you see any immediate problems I am
going to run into if I use Windows.Forms in multiple AppDomains?

SS

Hi Willy,

Again, thanks for the reply. You might be interested in reading (and,
perhaps, commenting on:)) my reply to Jon Skeet above. I've done some
experiments to clarify dependecies between message pumps running in different
AppDomains with regards to Application.Exit()