No, "myProcess.WaitForExit()" is the reason. If it waits it, when is it to
display the progressbar? Use "progressbar1.refresh" directly after showing
it.

The short solution in this case is: Handle the process' Exited event instead
of waiting for the exit.

Want some background information?....

The OS is message based. It sends messages to the applications, for example
to inform about user input like mouse clicks and keyboard input. The
application must process the messages. We can react to them by handling
Click (and other) events. The OS puts the messages into a queue because the
application might still be busy handling the previous message. It is called
the "message queue". The application processes the messages in a loop, one
after the other. It is called the "message loop".

The OS maintains a list of visually "invalidated" areas on the screen. If
you show a progress bar, the OS adds the control's rectangle to that list
because that part of the screen must be updated (I keep it simple here). In
addition, the OS sends a message (called WM_PAINT; WM=windows message) to
the application, more precisely to the control, in order to tell it that it
must paint itself.

If you specify a Form as the startup object in the project's properties, VB
internally creates a call to "Application.Run". Guess what "Run" does?
Right, it contains the message loop that processes the arrived messages. It
keeps the application responsive by processing the click notifications and
paint requests.

In your case, Sub Button1_Click is the reaction to a message. In it, you
display the progress bar. In short, this makes the OS send a message to the
progress bar in order to paint itself. As explained above, the message is
put in the queue, but as long as the Click message for the Button hasn't
been processed completely, the Paint message for the progress bar can not be
processed. That's how it is with sub procedures: The main procedure (the
message loop) won't continue before the sub procedure (Sub Button_Click) has
exited. Therefore, the progress bar isn't painted before the Click event
procedure exited.

Calling progressbar1.refresh /immediatelly/ paints the progress bar, but in
order to keep the whole Form responsive, you must return from Sub
Button_Click as soon as possible. Now we have a problem: On the one hand, we
want to wait and on the hand we want to keep on processing messages. There
is only one way to do two things at one time: Create another thread.
Multiple threads are meant to be executed synchronously. So, the solution is
to create another thread that does what has to be done simultaneously.

Multi threading explained:
http://msdn2.microsoft.com/en-us/library/3e8s7xdd.aspx
http://msdn2.microsoft.com/en-us/library/eed6swsx(VS.80).aspx

Armin