BackGroundWorker.ProgressChanged "Cross-thread operation not valid" at 2nd/3th/... progress

Hi,

I've tryed it, but it didn't work either :-/
And isn't the BackGroundWorker designed so we shouldn't worry anymore about
those Invoke and Delegates-stuff?

This is my new code with Invoke, which doesn't work either... :-/

Private Sub bgwInfoOutlook_ProgressChanged(ByVal sender As Object, ByVal
e As System.ComponentModel.ProgressChangedEventArgs) Handles
bgwInfoOutlook.ProgressChanged
Try
SetDataSource()
Catch ex As Exception
ErrorMessage(ex)
End Try
End Sub

Delegate Sub SetDgvCallback()

Private Sub SetDataSource()
If Me.dgvAdd.InvokeRequired Then
Dim d As New SetDgvCallback(AddressOf SetDataSource)
Me.Invoke(d, Nothing)
Else
Me.dgvAdd.DataSource = Nothing
Me.dgvAdd.DataSource = docCtrl.InfoList
End If
End Sub

And the werit thing is: the Me.dgvAdd.InvokeRequired returns False...

"Dmytro Lapshyn [MVP]" wrote in message
...
Hi Pieter,

As far as I know, .NET 2.0 strictly prohibits any access to the user
interface from background worker threads. This wasn't allowed in .NET 1.1
either, but in that version one sometimes could get away with violating
the rule. Now you'll get the "Cross-thread operation not valid" almost for
sure.

Therefore, to do any updates to the UI properly, you should use the
Control.Invoke method to run the UI update code on the UI thread.

The problem is more serious. You shouldn't be accessing any Outlook objects
from a background thread. It just won't work right and you'll have all sorts
of problems ranging from error messages to mysterious OUTLOOK.EXE processes
that won't shut down.

I'm afraid all of your communication with Outlook has to be done on the same
thread that calls your connect method. That would be the UI thread. The only
"async" methods you can use are the advanced search api's but I believe even
they are single-threaded much like a UI timer is.

--
Josh Einstein
Einstein Technologies
Microsoft Tablet PC MVP
Tablet Enhancements for Outlook 2.0 - Try it free for 14 days
www.tabletoutlook.com


"Pieter" wrote in message
...
Hi,

I've tryed it, but it didn't work either :-/
And isn't the BackGroundWorker designed so we shouldn't worry anymore
about those Invoke and Delegates-stuff?

This is my new code with Invoke, which doesn't work either... :-/

Private Sub bgwInfoOutlook_ProgressChanged(ByVal sender As Object,
ByVal e As System.ComponentModel.ProgressChangedEventArgs) Handles
bgwInfoOutlook.ProgressChanged
Try
SetDataSource()
Catch ex As Exception
ErrorMessage(ex)
End Try
End Sub

Delegate Sub SetDgvCallback()

Private Sub SetDataSource()
If Me.dgvAdd.InvokeRequired Then
Dim d As New SetDgvCallback(AddressOf SetDataSource)
Me.Invoke(d, Nothing)
Else
Me.dgvAdd.DataSource = Nothing
Me.dgvAdd.DataSource = docCtrl.InfoList
End If
End Sub

And the werit thing is: the Me.dgvAdd.InvokeRequired returns False...

"Dmytro Lapshyn [MVP]" wrote in message
...
Hi Pieter,

As far as I know, .NET 2.0 strictly prohibits any access to the user
interface from background worker threads. This wasn't allowed in .NET 1.1
either, but in that version one sometimes could get away with violating
the rule. Now you'll get the "Cross-thread operation not valid" almost
for sure.

Therefore, to do any updates to the UI properly, you should use the
Control.Invoke method to run the UI update code on the UI thread.

Why? COM in general (especially out-of-proc COM), and Outlook is particular
can handle cross thread/process calls just fine - all Outlook objects are
apartment threaded, so all calls will end up on the main Outlook thread
anyway.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Josh Einstein" wrote in message
...
The problem is more serious. You shouldn't be accessing any Outlook
objects from a background thread. It just won't work right and you'll have
all sorts of problems ranging from error messages to mysterious
OUTLOOK.EXE processes that won't shut down.

I'm afraid all of your communication with Outlook has to be done on the
same thread that calls your connect method. That would be the UI thread.
The only "async" methods you can use are the advanced search api's but I
believe even they are single-threaded much like a UI timer is.

--
Josh Einstein
Einstein Technologies
Microsoft Tablet PC MVP
Tablet Enhancements for Outlook 2.0 - Try it free for 14 days
www.tabletoutlook.com


"Pieter" wrote in message
...
Hi,

I've tryed it, but it didn't work either :-/
And isn't the BackGroundWorker designed so we shouldn't worry anymore
about those Invoke and Delegates-stuff?

This is my new code with Invoke, which doesn't work either... :-/

Private Sub bgwInfoOutlook_ProgressChanged(ByVal sender As Object,
ByVal e As System.ComponentModel.ProgressChangedEventArgs) Handles
bgwInfoOutlook.ProgressChanged
Try
SetDataSource()
Catch ex As Exception
ErrorMessage(ex)
End Try
End Sub

Delegate Sub SetDgvCallback()

Private Sub SetDataSource()
If Me.dgvAdd.InvokeRequired Then
Dim d As New SetDgvCallback(AddressOf SetDataSource)
Me.Invoke(d, Nothing)
Else
Me.dgvAdd.DataSource = Nothing
Me.dgvAdd.DataSource = docCtrl.InfoList
End If
End Sub

And the werit thing is: the Me.dgvAdd.InvokeRequired returns False...

"Dmytro Lapshyn [MVP]" wrote in
message ...
Hi Pieter,

As far as I know, .NET 2.0 strictly prohibits any access to the user
interface from background worker threads. This wasn't allowed in .NET
1.1 either, but in that version one sometimes could get away with
violating the rule. Now you'll get the "Cross-thread operation not
valid" almost for sure.

Therefore, to do any updates to the UI properly, you should use the
Control.Invoke method to run the UI update code on the UI thread.

Well as we discussed in another thread, there are pumping and re-entrance
problems with the STA model. But, I don't claim to understand all of these.
What I do know however, is that if I change a line of code in my app that
accesses any of the Outlook API from a background thread, Outlook will fail
to shut down.

I can't speak for out of process, but in process (such as in the case of an
add in) exhibits this behavior for me. It's also one of the main reasons I
gave up on trying to use remoting in another project. And in my research
(sorry I don't have sources at the moment, it was over a year ago) I found
others were recommending to not do this either.

--
Josh Einstein
Einstein Technologies
Microsoft Tablet PC MVP
Tablet Enhancements for Outlook 2.0 - Try it free for 14 days
www.tabletoutlook.com


"Dmitry Streblechenko" wrote in message
...
Why? COM in general (especially out-of-proc COM), and Outlook is
particular can handle cross thread/process calls just fine - all Outlook
objects are apartment threaded, so all calls will end up on the main
Outlook thread anyway.

Dmitry Streblechenko (MVP)
http://www.dimastr.com/
OutlookSpy - Outlook, CDO
and MAPI Developer Tool

"Josh Einstein" wrote in message
...
The problem is more serious. You shouldn't be accessing any Outlook
objects from a background thread. It just won't work right and you'll
have all sorts of problems ranging from error messages to mysterious
OUTLOOK.EXE processes that won't shut down.

I'm afraid all of your communication with Outlook has to be done on the
same thread that calls your connect method. That would be the UI thread.
The only "async" methods you can use are the advanced search api's but I
believe even they are single-threaded much like a UI timer is.

--
Josh Einstein
Einstein Technologies
Microsoft Tablet PC MVP
Tablet Enhancements for Outlook 2.0 - Try it free for 14 days
www.tabletoutlook.com


"Pieter" wrote in message
...
Hi,

I've tryed it, but it didn't work either :-/
And isn't the BackGroundWorker designed so we shouldn't worry anymore
about those Invoke and Delegates-stuff?

This is my new code with Invoke, which doesn't work either... :-/

Private Sub bgwInfoOutlook_ProgressChanged(ByVal sender As Object,
ByVal e As System.ComponentModel.ProgressChangedEventArgs) Handles
bgwInfoOutlook.ProgressChanged
Try
SetDataSource()
Catch ex As Exception
ErrorMessage(ex)
End Try
End Sub

Delegate Sub SetDgvCallback()

Private Sub SetDataSource()
If Me.dgvAdd.InvokeRequired Then
Dim d As New SetDgvCallback(AddressOf SetDataSource)
Me.Invoke(d, Nothing)
Else
Me.dgvAdd.DataSource = Nothing
Me.dgvAdd.DataSource = docCtrl.InfoList
End If
End Sub

And the werit thing is: the Me.dgvAdd.InvokeRequired returns False...

"Dmytro Lapshyn [MVP]" wrote in
message ...
Hi Pieter,

As far as I know, .NET 2.0 strictly prohibits any access to the user
interface from background worker threads. This wasn't allowed in .NET
1.1 either, but in that version one sometimes could get away with
violating the rule. Now you'll get the "Cross-thread operation not
valid" almost for sure.

Therefore, to do any updates to the UI properly, you should use the
Control.Invoke method to run the UI update code on the UI thread.

Oh I should also mention that your error here doesn't have anything to do
with the cross-thread Outlook access but I would avoid that anyway.

Your error message here is the same thing Dmytro said about cross-thread UI
calls. Something you are doing in DoWork (which is in a background thread)
is modifying the data grid. You can't do any UI access in DoWork. Only in
ProgressChanged or RunWorkerCompleted.

But again, I would avoid accessing the Outlook API from a background thread.
It is not thread-safe and behaves unpredictably whether or not you employ
locking.

--
Josh Einstein
Einstein Technologies
Microsoft Tablet PC MVP
Tablet Enhancements for Outlook 2.0 - Try it free for 14 days
www.tabletoutlook.com


"Pieter" wrote in message
...
Hi,

I've tryed it, but it didn't work either :-/
And isn't the BackGroundWorker designed so we shouldn't worry anymore
about those Invoke and Delegates-stuff?

This is my new code with Invoke, which doesn't work either... :-/

Private Sub bgwInfoOutlook_ProgressChanged(ByVal sender As Object,
ByVal e As System.ComponentModel.ProgressChangedEventArgs) Handles
bgwInfoOutlook.ProgressChanged
Try
SetDataSource()
Catch ex As Exception
ErrorMessage(ex)
End Try
End Sub

Delegate Sub SetDgvCallback()

Private Sub SetDataSource()
If Me.dgvAdd.InvokeRequired Then
Dim d As New SetDgvCallback(AddressOf SetDataSource)
Me.Invoke(d, Nothing)
Else
Me.dgvAdd.DataSource = Nothing
Me.dgvAdd.DataSource = docCtrl.InfoList
End If
End Sub

And the werit thing is: the Me.dgvAdd.InvokeRequired returns False...

"Dmytro Lapshyn [MVP]" wrote in message
...
Hi Pieter,

As far as I know, .NET 2.0 strictly prohibits any access to the user
interface from background worker threads. This wasn't allowed in .NET 1.1
either, but in that version one sometimes could get away with violating
the rule. Now you'll get the "Cross-thread operation not valid" almost
for sure.

Therefore, to do any updates to the UI properly, you should use the
Control.Invoke method to run the UI update code on the UI thread.

"Josh Einstein" wrote in message
...

Your error message here is the same thing Dmytro said about cross-thread
UI calls. Something you are doing in DoWork (which is in a background
thread) is modifying the data grid.

Well actually it isn't :-/
And I don't have the exception while the Dowork is performing its actions:
it happens when the ProgressChanged-event fires...

You'll have to recheck your code. Set a breakpoint and look at the threads
window. You are definitely accessing the UI from the background thread
somewhere. ProgressChanged and RunWorkerCompleted are raised on the UI
thread. (Which is why InvokeRequired returns false.)

--
Josh Einstein
Einstein Technologies
Microsoft Tablet PC MVP
Tablet Enhancements for Outlook 2.0 - Try it free for 14 days
www.tabletoutlook.com


"Pieter" wrote in message
...
"Josh Einstein" wrote in message
...

Your error message here is the same thing Dmytro said about cross-thread
UI calls. Something you are doing in DoWork (which is in a background
thread) is modifying the data grid.

Well actually it isn't :-/
And I don't have the exception while the Dowork is performing its actions:
it happens when the ProgressChanged-event fires...