Link to home
Start Free TrialLog in
Avatar of pearlym
pearlym

asked on

Screen getting blank while running

i have a form with a button and a status bar on it
i have a simple coding like this on button click event
        Dim i As Integer
        For i = 1 To 100000
           TextBox1.Text = i
            i = i * 1
            StatusBar1.Text = " Hai my value is " & i
        Next
During this process of running the coding if i minimise the form and open someother
program and after that if i again open the vb.net form i get a blank screen. The form controls
reappears only after the complete process is done
Can anybody help me witrh this
Avatar of gangwisch
gangwisch

yes you need threading. Also keep in mind that another thing that is slowing your process down is i=i*1 (kind of senseless).

This is only worth 25 points so i will stop here. I hope in the future you will give experts more
credibility with more points. But with 25 points it just seems like you dont appreciate my time.
ASKER CERTIFIED SOLUTION
Avatar of newyuppie
newyuppie
Flag of Ecuador image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Fernando Soto
Hi pearlym;

The reason why the User Interface is unresponsive after minimizing the window and then reopening it is due to the face that the program is running in a single thread of execution. So what is happening is that when you click on the button to run the button click event handler no other code is running in you application and no other events are being handled until the code in question is completed. You will note if you haven’t already is that the value in the text box does not change either until you come back from the button click event. To solve your problem you can do one of two things, 1. create a new thread for that code as gangwisch states in his post or 2. Insert an statement inside the For loop, Application.DoEvents( ) as newyuppie has stated.  In solution 1 the new thread runs concurrently with the User Interface thread and so the UI will respond. In solution 2 the DoEvents will go to the threads message loop to see if there are any events that need to be taken care of and then return back to continue working on the code that had called it. Solution 2 is much easier in this case.

As newyuppie stated, i = i * 1 does nothing except waste more time in the loop. Another thing about this line of code is that this is bad programming practice. You should never adjust the loop control variable it could cause you problems.

Have a great day;

Fernando
It's important to note that simply placing code in another thread does not magically "free up" your main UI thread so it remains responsive.

What you have there is a tight processing loop which as Fernando explained prevents your app from processing its normal messages because it is "stuck" in the loop.

So what happens if you place that code in another thread?  The main UI thread no longer gets "stuck" in the loop...BUT the GUI STILL has to update itself for EVERY iteration of the loop!  So we really haven't freed it up much at all.  We still expect it to do just as much work as before, but because of the new thread involved we actually have given it more work since it now has to use the Invoke() method with Delegates to marshal the calls across the threads.

So how can we fix that?  One way is to "throttle" the loop back so it isn't so "tight" anymore.  Since the loop is now in its own thread we can safely put it to sleep without causing the main UI thread to freeze up:

        For i As Integer = 1 To xxx
            ' ... code ...

            ' make this thread stop briefly
            ' thus giving other threads a
            ' chance to do their own thing
            ' without being constantly
            ' pestered with our info...
            System.Threading.Thread.Sleep(yyy)
        Next

Another option is to not force the GUI to update for every iteration of the loop.  You could update the the GUI every 10 iterations for instance.

But when dealing with long operations ask yoursef:

    Does the user REALLY need to see every single "step" in the process?

Often times the info is flying by so fast that the user can't even read it.  It is just a waste of processor time.  Most users are happy as long as there is some indication that the process is still ongoing.  This can be accomplished with updates as far apart as every 1/2 second.

One final thought:  Sometimes it makes sense to reverse the update direction.  Instead of the thread telling the GUI when to update...the GUI can "query" the thread.  You can place a Timer on the form that periodically grabs a value from the thread (you can use a global variable here for simplicity) and displays it in a control.

~IM