Backgroundworker and controls

[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.

[Armin Zingler]

"Johnny Jörgensen" <jo**@altcom.seschrieb

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.

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

[Johnny Jörgensen]

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

/Johnny J.

"Armin Zingler" <az*******@freenet.deskrev i meddelandet
news:uc**************@TK2MSFTNGP06.phx.gbl...

"Johnny Jörgensen" <jo**@altcom.seschrieb

>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.

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

[rowe_newsgroups]

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

[Phill W.]

Johnny Jörgensen wrote:

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"

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.

[=?iso-8859-1?q?Horacio_Nu=F1ez_Hern=E1ndez?=]

On 1 ago, 07:01, "Johnny Jörgensen" <[e-mail]:

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.

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

[Peter Duniho]

Horacio Nuñez Hernández wrote:

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

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

[Peter Duniho]

Johnny Jörgensen wrote:

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

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

[Jon Skeet [C# MVP]]

Horacio Nuñez Hernández <hn******@gmail.comwrote:

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

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[mpetrotta]

On Aug 1, 4:47 am, rowe_newsgroups <[e-mail]:

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.

.... 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

[Cor Ligthert[MVP]]

Jon,

Snip

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

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

[Jon Skeet [C# MVP]]

Cor Ligthert[MVP] <no************@planet.nlwrote:

Snip

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

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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Peter Duniho]

Cor Ligthert[MVP] wrote:

Jon,

Snip

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

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""

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

[Cor Ligthert[MVP]]

Jon and Peter,

My excuse, I was only looking at your replies.

Cor

"Jon Skeet [C# MVP]" <sk***@pobox.comschreef in bericht
news:MP*********************@msnews.microsoft.com. ..

Cor Ligthert[MVP] <no************@planet.nlwrote:

>Snip

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

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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too