MessageBox.Show has forms like MessageBox.Show( ownerWindow, .... ).
What do I gain by assigning a owner window?
See Question&Answers more detail:osMessageBox.Show has forms like MessageBox.Show( ownerWindow, .... ).
What do I gain by assigning a owner window?
See Question&Answers more detail:osA message box is a modal form, which means that its parent window is disabled until the message box is dismissed.
If a Show() overload is called that does not take an owner identifier, then a parent form is usually chosen automatically. I can't find anything in the documentation that describes how that form is chosen, but my experience is that if the message box is displayed inside the GUI thread (i.e., the main thread, or message pump thread), then the active window for that thread is chosen as the parent.
Other threads may create message boxes with no parent form. This could be a bad situation, because it could sit behind the active window, and the user will not even know it is there until they close the program. To avoid this, you could pass the handle of the application's main window to the Show method, which will disable that window for the duration of the message box.
ADDED: I've been thinking about this and now I'm not so sure. The snippet from reflector that you gave below makes me think that maybe the thread doesn't matter. (I did say that I couldn't find anything in the documentation!)
I'd have to go back and look at the code to make sure, but I think the message boxes that I used to lose behind the main form may have actually been custom message box forms, in which case my experience is faulty, and you never ever have to supply a parent form parameter.
Sorry for the confusion.
My recommendation now is to never supply this parameter unless you need something other than the active window to be the main form.