Backgroundworker and controls

  • Thread starter Thread starter Johnny Jörgensen
  • Start date Start date
J

Johnny Jörgensen

Hi I have a procudure that takes some time and thus slows down the main
system. I want to put it in a backgroundworker component to run it
asynchroneously. But in the procedure, I want to update a TreeView control I
have on my main form.

When I try to do that, I get the error "Cross-thread operation not valid:
Control 'TreeView1' accessed from a thread other than the thread it was
created on"

I seem to have read something about that poblem before, but can't remember
if there's a solution to it...

Please advice asap,
Johnny J.
 
Johnny Jörgensen said:
Hi I have a procudure that takes some time and thus slows down the
main system. I want to put it in a backgroundworker component to run
it asynchroneously. But in the procedure, I want to update a
TreeView control I have on my main form.

When I try to do that, I get the error "Cross-thread operation not
valid: Control 'TreeView1' accessed from a thread other than the
thread it was created on"

I seem to have read something about that poblem before, but can't
remember if there's a solution to it...

Please advice asap,
Johnny J.
Click to expand...


Call the control's BeginInvoke function ([F1] for details). The invoked
function will run in the thread that created the control, which is allowed
to access it.


Armin
 
But won't that be the same thread as my main thread???

/Johnny J.



Armin Zingler said:
Johnny Jörgensen said:
Hi I have a procudure that takes some time and thus slows down the
main system. I want to put it in a backgroundworker component to run
it asynchroneously. But in the procedure, I want to update a
TreeView control I have on my main form.

When I try to do that, I get the error "Cross-thread operation not
valid: Control 'TreeView1' accessed from a thread other than the
thread it was created on"

I seem to have read something about that poblem before, but can't
remember if there's a solution to it...

Please advice asap,
Johnny J.
Click to expand...


Call the control's BeginInvoke function ([F1] for details). The invoked
function will run in the thread that created the control, which is allowed
to access it.


Armin
Click to expand...
 
But won't that be the same thread as my main thread???

Yes.

The problem is that the background worker's thread is not your main
thread, which is why you need to use BeginInvoke to delegate control
back to the main thread.

Thanks,

Seth Rowe
 
Johnny said:
Hi I have a procudure that takes some time and thus slows down the main
system. I want to put it in a backgroundworker component to run it
asynchroneously. But in the procedure, I want to update a TreeView control I
have on my main form.

When I try to do that, I get the error "Cross-thread operation not valid:
Control 'TreeView1' accessed from a thread other than the thread it was
created on"
Click to expand...

But the whole point of the Background worker is that it raises events
(ProgressChanged, RunWorkerCompleted, etc) as the background job proceeds.

Most importantly, these events are raised /on the UI thread/, so you can
update Controls any way you like.

HTH,
Phill W.
 
Hi I have a procudure that takes some time and thus slows down the main
system. I want to put it in a backgroundworker component to run it
asynchroneously. But in the procedure, I want to update a TreeView control I
have on my main form.

When I try to do that, I get the error "Cross-thread operation not valid:
Control 'TreeView1' accessed from a thread other than the thread it was
created on"

I seem to have read something about that poblem before, but can't remember
if there's a solution to it...

Please advice asap,
Johnny J.
Click to expand...

Put in the a place before you call the background compontent to start
checkforillegalcrosscall = false //im not in front the vs but the
property is something like that

check that the doesnt fire only on debug
 
Horacio said:
Put in the a place before you call the background compontent to start
checkforillegalcrosscall = false //im not in front the vs but the
property is something like that
Click to expand...

No. Do NOT do that. All that does is turn off the error detection.
The error still exists.

The first reply from Armin was the best: use BeginInvoke() (or Invoke())
to run code that updates the UI. Yes, that will cause the code (just
the code in the invoked method) to run in the main thread. That's the
whole point, and is exactly what needs to be done.

Pete
 
Johnny said:
But won't that be the same thread as my main thread???
Click to expand...

Yes, it will. That's the point.

To be clear: only the code that does the actual updating of the control
needs to be called via Invoke() or BeginInvoke(). Armin isn't
suggesting that you call _all_ of the BackgroundWorker code via
Invoke(). Just the code that needs to manipulate your UI elements, such
as the TreeView control being updated.

Pete
 
Horacio Nuñez Hernández said:
Put in the a place before you call the background compontent to start
checkforillegalcrosscall = false //im not in front the vs but the
property is something like that

check that the doesnt fire only on debug
Click to expand...

The whole point of the exception is to show that you're doing something
wrong. You shouldn't access a control from any thread other than the
one running its message loop.

Setting the property to false just hides the problem temporarily
instead of solving it.
 
Yes.

The problem is that the background worker's thread is not your main
thread, which is why you need to use BeginInvoke to delegate control
back to the main thread.
Click to expand...

.... and just to be clear, if you want to call a member of your
control, you *must* do it on your UI ("main") thread. More precisely,
you must call members of a control from the thread on which that
control was created. This is a requirement specific to WinForms
controls.

More information here:
http://msdn2.microsoft.com/en-us/library/3s8xdz5c.aspx

(technically, it's not a requirement, just a really, really good idea,
one that's enforced by a VisualStudio MDA exception. Windows controls
are not thread-safe in that way, and you'll get unpredictable,
intermittent errors if you try to work around it.)

Michael
 
Jon,

Snip
The whole point of the exception is to show that you're doing something
wrong.
Click to expand...

I won't tell it in this way, more "There is something going wrong". By
instance when a server goes down then this can be catched during the proces.
Better in my eyes it is a must to catch this, however that has nothing to do
with "That you are doing something wrong""

I know that it is just an expression, however in my eyes should this be used
more for the exception instead of catching program errors, what I have seen
is done to much. The last in fact in the same way as Peter writes this.

Cor
 
Cor Ligthert said:
Snip

I won't tell it in this way, more "There is something going wrong". By
instance when a server goes down then this can be catched during the proces.
Better in my eyes it is a must to catch this, however that has nothing to do
with "That you are doing something wrong""

I know that it is just an expression, however in my eyes should this be used
more for the exception instead of catching program errors, what I have seen
is done to much. The last in fact in the same way as Peter writes this.
Click to expand...

No, this exception is *specifically* aimed at developers to tell them
that they're doing something wrong. It's not there to let you do clean-
up etc - it's pointing out a bug.

That's why by default it only occurs in debug mode. If it were there to
allow clean-up etc in the case of failure, it would happen in release
mode too.
 
Cor said:
Jon,

Snip

I won't tell it in this way, more "There is something going wrong". By
instance when a server goes down then this can be catched during the
proces. Better in my eyes it is a must to catch this, however that has
nothing to do with "That you are doing something wrong""
Click to expand...

Perhaps what you write makes sense for exceptions generally. However,
this particular exception very much is about "you're doing something
wrong". That is, it doesn't catch an actual "something going wrong".
The code may in fact work much of the time, even when this exception occurs.

The MDA exception is in fact specifically saying "you are doing
something wrong".

Pete
 
Back
Top