2

On a different question I suggested to use

private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{
    while (processingLock)
        Application.DoEvents();
}

in the FormClosing event (with processingLock becoming false immediately after a lengthy calculation was done). It should serve the purpose to have the application close down in an orderly manner and the original poster didn't use threads.

On my suggested answer somebody commented that DoEvents is never good, providing this link: Use of Application.DoEvents()

I read and (I think) understood the issue. In my opinion (which is still noobish) there is no risk for confusing events to happen if I use DoEvents as above in the FormClosing event - if there is no way to cancel the closing for the user (like setting e.Cancel = true).

My question: is this a valid method to make sure an application is terminated well and if not, why?

Community
  • 1
  • 1
Johannes Schöck
  • 177
  • 10
  • 1
    What do you expect to happen when the user madly bangs the window's Close button to try to get it closed, firing the FormClosing event repeatedly? If you don't know, surely you don't, are you comfortable about writing code whose behavior you cannot predict? Have you at least tested it? There is never a good reason to avoid writing correct code, you can hide the window and close it when the "processing" ends. – Hans Passant Aug 25 '14 at 09:22

1 Answers1

0

Thanks to comments and more thinking about the relevant posts I've figured out why this "special case" with FormClosing is not special after all.

The problem is that the form is not disabled during the FormClosing event. The user can not only try to close the form several times (which would be okay in this scenario), but she can also click any other UI elements - leading to the problems with uncertain execution order etc. that are mentioned in the linked article.

Hard concept for noobs, thanks for you input.

Johannes Schöck
  • 177
  • 10