In addition to Solution 1.
Even though triggering the window operation by a UI event is quite possible, it means logically wrong routing of events, mixing up causes and consequences. Progress bar, if used according to its intended design, really means some lengthy operation; technically it should mean that you have some non-UI thread doing its job. Let's denote this thread and all events on this thread (such as update of its progress percentage and completion) as "
Th". Let's consider cause-consequence graph between the events in question:
Bad:
Th ────> progress bar ─────> show form
Good:
Th ────> progress bar
│
└──────> show form
Solution 1 perfectly explains why the case I depicted as "Bad" is really bad. More generally, you try to technically express the behavior of the application in a way not following its logic. Even if the results are formally equivalent, it is translated into considerable hardship in maintenance.
Now, how the non-UI thread should notify UI to make is showing a window (using
Form.Show) and updating the
ProgressBar.Value? You cannot call anything related to UI from non-UI thread. Instead, you need to use the method
Invoke or
BeginInvoke of
System.Windows.Threading.Dispatcher (for both Forms or WPF) or
System.Windows.Forms.Control (Forms only).
You will find detailed explanation of how it works and code samples in my past answers:
Control.Invoke() vs. Control.BeginInvoke()[
^],
Problem with Treeview Scanner And MD5[
^].
See also more references on threading:
How to get a keydown event to operate on a different thread in vb.net[
^],
Control events not firing after enable disable + multithreading[
^].
—SA
Submit an article or tip