Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>We finally found more about this (but by then my machine had been rebuilt and lost the cookies to my unregistered profile here; hopefully, it will let met post this answer).</p> <p>Further investigation eventually found a few more events which we have found helpful:</p> <p><code>System.Windows.Forms.Application.ThreadExit</code> - Fires when a message loop exits <code>System.Windows.Forms.Application.ApplicationExit</code> - Fires when all message loops exit <code>System.AppDomain.CurrentDomain.DomainUnload</code> - Fires when a domain other than the default exits <code>System.AppDomain.CurrentDomain.ProcessExit</code> - Fires when the default app domain exits <code>System.AppDomain.CurrentDomain.UnhandledException</code> - Fires when an uncaught exception occurs, ending the app.</p> <p>Only one of the <code>DomainUnload</code> or <code>ProcessExit</code> events are possible for a given app domain, depending on whether it is the default (top-level) domain for the process or was created as a subdomain (eg. on a web server). If an application doesn't know which it might be (as in our case), it needs to subscribe to both if it wants to catch the actual unload for itself. Also, it appears that <code>UnhandledException</code> (which as of .NET2.0 is always fatal) may prevent the other two events, so that may be a third case to handle. These three events should work for any .NET application.</p> <p>There is a caveat that the execution time for <code>ProcessExit</code> is bounded (about 4 seconds?), so it may not be possible to do extensive "final" work in that event handler. It needs to be something which can be done quickly.</p> <p>The <code>Application</code> events only apply to WinForms applications (we suspect they may not apply in pure WPF applications, however). The naming can be misleading because they are named for their most basic normal usage which has certain assumptions. <code>ThreadExit</code> does not relate to the actual <code>System.Threading.Thread</code> but rather to the message loop (<code>Application.Run()</code>)) of a UI thread, and <code>ApplicationExit</code> similarly relates to the collection of application Forms on one or more UI threads. Normally, once the call to <code>Application.Run()</code> returns, called from the entry method of a thread, the entry method quickly concludes and the thread itself then ends. And once all UI threads have exited, a WinForms app is usually all done and exits.</p> <p>Another event of note is the <code>System.Windows.Forms.Application.ThreadException</code> event. A Windows message loop can be configured to catch exceptions which occur in handling a message and send this event rather than let them be uncaught (and thus fatal) exceptions. Catching these exceptions allows the message loop (and that UI thread) to continue running (after aborting the current message handler). There can be only one subscriber to this event at any time for a given thread (subscriptions overwrite any previous subscriber), and it must be configured before any Form is created and subscribed before entering the message loop. See the MSDN help for this event and <code>System.Windows.Forms.Applicaton.SetUnhandledExceptionMode()</code> for more info.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload