Windows Forms

25-Feb-08 2:59

Hi,

I have 1 WindowsForm with 2 BackGround Workers.
Each BGW runs a process.
Each BGW has its own DatagridView and textbox as display ouptut when the ProgressChanged eventhandler is called.

So I see to textboxes running with text to see how far each process is.

My problem now is that when I click on my Form or on the Windows Desktop and than on my program again the windows form freezes, says (Not Responding). In the taskmanager I can see the program is still running.
After 10 minutes or so the application continues with show logtextx in the textboes en show how manu rows were proccessed.

How can I solve thi sproblem. I want the program to continue working if I click on the form.

Luc Pattyn25-Feb-08 5:09

25-Feb-08 5:09

Hi,

only the thread that creates a Control (Form, DGV, ...) is allowed to access it; all other
threads (such as BGW) should keep off, i.e. they need to use Control.InvokeRequired and
Control.Invoke to tell the owning thread to perform the access.

If not, either the GUI may/will freeze, the app will crash, or (since .NET 2.0) you will
get an illegal-cross-thread exception (which you can hide, but you can't hide the freezing
effects).

There are lots of articles on InvokeRequired etc., both on CodeProject and Google.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.

Herman<T>.Instance26-Feb-08 2:14

26-Feb-08 2:14

This is strange!

I am using the backgroundworker. The UI Thread starts the BackGroundWorker in a new thread.
The BackGroundWorker has 2 events called ProgressChangedEventHandler and RunWorkerCompletedEventHandler but they run in the GUI-Thread. By using the method ReportProgress(0) of the BackGroundWorker it is possible to update GUI-components in the ProgressChangedEventHandler.
No need for Control.InvokeRequired in here. And by using this way of BackGroundWorker no Illegal-Cross-Exceptions occur.

In the BackGroundWorker you must check if (BackGroundWorker.CancellationPending.Equals(true)) and then you can set the e.Cancel object.

Can a backgroundprocess consume so much from a pc (my processor show 30% usage) that the Form-Buttons freeze?

Luc Pattyn26-Feb-08 2:31

26-Feb-08 2:31

Hi,

which threads starts the BGW is irrelevant; the BGW always runs its own thread, which is
different from the GUI thread.

yes, ProgressChangedEventHandler and RunWorkerCompletedEventHandler will be run by
the GUI thread, no problem inside those handlers.
however, if your BGW itself tries to access Controls, a freeze is likely to occur.

MSDN says "You must be careful not to manipulate any user-interface objects in your
DoWork event handler. Instead, communicate to the user interface through the
ProgressChanged and RunWorkerCompleted events."

digimanus wrote:
Can a backgroundprocess consume so much from a pc (my processor show 30% usage) that the Form-Buttons freeze?

AFAIK no, unless you manage to change the relative thread priorities.

Final thought: what is in your GUI code right after starting the BGW? You are not
waiting somehow for it to finish, do you?

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

Herman<T>.Instance26-Feb-08 4:18

26-Feb-08 4:18

private void button1_Click(object sender, EventArgs e)
        {
            try
            {

                txtInfo.Text = String.Empty;
                txtInfo2.Text = String.Empty;
                MeldingenNaarStatus1 = String.Empty;
                MeldingenNaarStatus2 = String.Empty;
                button1.Enabled = false;
                button2.Enabled = true;
                naarMultizorgStat0.Open();
                naarMultizorgStat1.Open();
                naarMZ2.Open();
                naarNDFACC.Open();
                naarNDFACC2.Open();
                bgwNaarStatus1.RunWorkerAsync();
                bgwNaarStatus2.RunWorkerAsync();
            }
            catch (Exception err)
            {
                tssLabel1.Text = err.Message;
            }
          
        }

Hi Luc,

I do not touch any GUI object in the BGW.
In the BGW I fill a String-object with text.
In the report progress I fill the txtInfo.Text with the filled String Object.
If the String object > 20000 characters or the multiline TextBox txtInfo is over 100 lines, the txtInfo.text is set to String.Empty;
This is done in the reportprogress

If the BGW is finished it runs the RunWorkerCompleted-eventhandler.

Has it to do with the fact I am using 2 BGW's?
The first BGW checks for 600000+ records if the status is 0, check in another database if he can find the relative and set status to 1 (if found) or -1 if not found.
This process is done by 10000 database rows.

The second proces checks for all records with Status=1 if the financial numbers are in the database.
If found an agreement for the financial numbers Status will become 2 otherwise an angreement, a payment and so on will be insert in the database.
This is done in batches of 25 records unless BGW 1 is finished (a Boolean will tehn be true).
Batches will than have a size of 1000 rows.

Is this just to much for .NET?

Luc Pattyn26-Feb-08 4:49

Re: Form with BackGroundWorkers [modified]

26-Feb-08 4:49

Hi,

there is nothing fundamentally wrong it what you told here; this could work just fine.
The amount of work is actually irrelevant: when implemented properly the GUI should stay
alive and responsive at all times, and all the work is done, well, in the background.

Now here is maybe a clue: if one of your BGWs is keeping the database very busy
(and if the DB is on another machine, it would not show in your client's CPU activity),
then any other DB request may be delayed for quite some time. Now lets assume something
else in the GUI thread is trying to do a DB access too, that could temporarily
slow down the GUI so it looks frozen, no longer shows the menu bar, whatever.
And that something could be a Window.Forms.Timer doing some simple job periodically...

Of course this is just a hunch; anyway, I suggest you look for an indirect way in which
the GUI gets hampered by the BGW (stealing too many CPU cycles due to thread priority,
stealing DB bandwitdh, a locked object, a locked file, whatever).

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

Herman<T>.Instance26-Feb-08 5:00

26-Feb-08 5:00

Both BGW connect to 2 different Database on different machines.
Process 1 is a fast one but the second is a time consuming one.
It has to check in 11 tables in 1 query. If that gives two rows of result the next agreement has to be found.
I use about 100 queries for determining the proces for 1 DBC in an arraylist.

What I do each time is to add an object in an arraylist. Based on the data in the datareader containing 25 or 1000 lines for proces 2 and 10000 lines for proces 1.

I did create an OnActiveChanged event for the Form and if I add Application.DoEvents(); The freeze get a bit less.
That's all!

Small Test results
I did check the DatabaseServer that will receive the information via Insert INTO sql's.
When I start my program the Database is at 0%. As soon as I hit the Start button the CPU for SqlServer raises up to 40-50%. It stays stable until I press the Cancel button.
My program freezes and the SqlServer user 70-80%........
This is NOT funny Frown | :(

modified on Tuesday, February 26, 2008 11:08 AM

Luc Pattyn26-Feb-08 5:14

26-Feb-08 5:14

Hi,

Application.DoEvents() is a dangerous thing, you must make sure you don't call it
recursively (if you do all things may happen, including StackOverflow and less
obvious problems).

When Application.DoEvents() at a particular spot in the code improves the behavior,
that typically means that code ~~that~~ should not execute on the thread it is, but should
be ran by a background thread instead.

What is your OnActiveChanged event? when does it fire, and what is in its handler?
Any idea how often it fires? could it be firing all the time, overloading the GUI
thread with unnecessary work? could it include some delays (say larger than 10 msec,
either a Thread.Sleep or some kind of wait for something)
making the GUI slow but keeping CPU cycles low?

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

modified on Tuesday, February 26, 2008 11:53 AM

Herman<T>.Instance26-Feb-08 6:03

26-Feb-08 6:03

Deleted the eventhandler for OnActiveChanged. Used it for when Someone click beside the the app and then clicked on the app again. that is the moment of freeze.
removing the eventhandler did not solve....
Seeing in the sql profiler it needs for simple CRUD-work over 13000 reads.....
Time to do some indexing I believe

Luc Pattyn26-Feb-08 6:09

26-Feb-08 6:09

Hi,

improving the DB performance is good, but with what you told me, I would say it is
not at the hearth of the problem; your GUI should behave well no matter how fast
or slow the servers are. I still think something is wrong in your client code,
your GUI gets bogged down by something that should not run on or block the GUI thread.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

Herman<T>.Instance26-Feb-08 23:01

26-Feb-08 23:01

Found IT!

I have 2 dataGridViewComponents and they are refreshed in the ReportProgress events.
Since there are heavy SQL's involved for both dgv's it hang up the app.
I removed these dgv's and their fill ups. It's running smoothy now.

would it be wise to update these dgv's in a timer event (UI Thread!)?
Or better leave them out?

I leaving them out the user cannot see how far the process is.

Luc Pattyn26-Feb-08 23:50

Re: Form with BackGroundWorkers [modified]

26-Feb-08 23:50

Hi,

moving the code that does DB access and DGV update to a Windows.Forms.Timer does not help at all:
the DB access, which is presumably the slow part of it, would block the GUI for as long as it takes.

The right approach would be to split the actions into:
1. some code that does the DB access but does not touch the GUI
2. code that updates the GUI

1. should be organized on a BGW, a thread or a timer (NOT a Windows.Forms.Timer), so it runs
independent of the GUI
2. must run on the GUI

I tend to use some intermediate data structure (say a generic list) to collect results and
prepare them for display (1), then pass it all on to some simple code that updates the GUI (2)
at high speed, hence never blocking the GUI thread and GUI for more than a few milliseconds.

digimanus wrote:
leaving them out the user cannot see how far the process is.

It is considered bad design to have a long winding operation that does not report progress
(the user may think the app died); and offering a cancel option (button) is recommended.

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

Herman<T>.Instance27-Feb-08 1:15

27-Feb-08 1:15

Hey Luc,

build a 3rd BGW which runs while bgw1 or bgw2 isbusy!
Unless bgw1 or bgw2 has received cancellation pending.
It loads the queryresult in a DataSet.
In the reportprogress for the 3rd BGW the dataset.tables[0] is attachted as datasource to dgv1 and dgv2 (2 datasets, each dgv has it's own).

The user has its view in the progress, sees the statistics run, no GUI Freeze.
Start and Cancel work great.

Thanx for helping me out!

[Added]
Been testing for a while.
You what freezes.... object.Refresh();
Removing that helps a lot in the performance
The project now runs fine on a server some 6 floors lower.

modified on Wednesday, February 27, 2008 9:21 AM

Luc Pattyn27-Feb-08 4:04