Hi all.

I have encountered a "Cross-thread operation not valid" error in a
test program I created and although I have came up with a solution I
don't like the performance of the program.

I hope perhaps some experts here can help me out.

Here is what my program consists of:
1) A form containng several tabs, one of which contains a ListView
control named "lvwFileList" and two buttons control to start and stops
a background process.
2) The backgroun process is done using the BackgroundWorkder control
and it calls a procedure named "ProcessFileList" which loops through
all items in the ListView control on the main form.

Here is my revision 1 of the procedure:
Private Sub ProcessFileList
Dim lvwItem as ListViewItem
For Each lvwItem in lvwFileList
'do some processing and update the ListView control
Next lvwItem
End Sub

Calling this procedure from a BackgroundWorker thread will result in a
"Cross-thread operation not valid"" error when the procedure attempts
to access "lvwFileList".

My next revision of the procedure uses methdodinvoke to get around the
"cross-thread" error:
Private Sub ProcessFileList
If Me.InvokeRequired Then
Me.Invoke(New MethodInvoker(AddressOf ProcessFileList))
Else
Dim lvwItem as ListViewItem
For Each lvwItem in lvwFileList
'do some processing and update the ListView control
Next lvwItem
End If
End Sub

This procedure will invoke a delegate method to run in the main form's
thread and therefore can access the listview control directly. The
process will run but the main form's interface becomes unresponsive
unless I insert Application.Doevents() into the loop. But even with
Application.Doevents inserted, the form's user interface is still
sluggish. For example, jumping between different tabs on the form
takes about 2-3 seconds after each mouse click. FYI, the loop process
itsef does not use much CPU resources. According to Windows Task
Manager, the process contributed to only 3% of CPU utilization.


Does anyone know a better way to access a control from a
backgroundwoker thread?
Is it possible to create a delegate to a control?

I am interested in a solution that allows me to continue to use the
For ... Each statement to process and update the listview.

Something like "For Each lvwItem In ListviewDelegate".

I already know how to access individual list view items in the by
using a delegate method. If I do that I will be forced to call the
delegate method in the loop for every listview item I want to access.
Also I will have to get the nubmer of listview items first and use the
regular For ... Next in the loop instead.

The reason I prefer the For ... Each loop is because I have a
FileSystemWatcher process running in the background that will add or
remove items from the listview control automatically. So if new items
are added to the listview control during the For ... Each loop
processing, they will also be included in the processing as long as
the For ... Each loop has not finished.

If there is no way to use For ... Each statement the way I would like,
I guess I will need to figure out how to make the main form more
responsive using my current approach.

Any comments or suggestions would be appreciated.

Thank you.
Jason

(E-Mail Removed) wrote in news:(E-Mail Removed):

> Does anyone know a better way to access a control from a
> backgroundwoker thread?
> Is it possible to create a delegate to a control?

You only need to "invoke" when updating something on the form.

Thus, if the majority of your background thread is looping, calculating,
fetching data... then you can only call "invoke" when you update an element
(i.e. set an item text property etc.).

Well this can be solved verry easy , just load the items in a array , data
table , hashtable or whatever
pefform your operations with the items in this .

as last action you set them to the listview control for your user to see
with a delagate

regards

Michel



<(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
> Hi all.
>
> I have encountered a "Cross-thread operation not valid" error in a
> test program I created and although I have came up with a solution I
> don't like the performance of the program.
>
> I hope perhaps some experts here can help me out.
>
> Here is what my program consists of:
> 1) A form containng several tabs, one of which contains a ListView
> control named "lvwFileList" and two buttons control to start and stops
> a background process.
> 2) The backgroun process is done using the BackgroundWorkder control
> and it calls a procedure named "ProcessFileList" which loops through
> all items in the ListView control on the main form.
>
> Here is my revision 1 of the procedure:
> Private Sub ProcessFileList
> Dim lvwItem as ListViewItem
> For Each lvwItem in lvwFileList
> 'do some processing and update the ListView control
> Next lvwItem
> End Sub
>
> Calling this procedure from a BackgroundWorker thread will result in a
> "Cross-thread operation not valid"" error when the procedure attempts
> to access "lvwFileList".
>
> My next revision of the procedure uses methdodinvoke to get around the
> "cross-thread" error:
> Private Sub ProcessFileList
> If Me.InvokeRequired Then
> Me.Invoke(New MethodInvoker(AddressOf ProcessFileList))
> Else
> Dim lvwItem as ListViewItem
> For Each lvwItem in lvwFileList
> 'do some processing and update the ListView control
> Next lvwItem
> End If
> End Sub
>
> This procedure will invoke a delegate method to run in the main form's
> thread and therefore can access the listview control directly. The
> process will run but the main form's interface becomes unresponsive
> unless I insert Application.Doevents() into the loop. But even with
> Application.Doevents inserted, the form's user interface is still
> sluggish. For example, jumping between different tabs on the form
> takes about 2-3 seconds after each mouse click. FYI, the loop process
> itsef does not use much CPU resources. According to Windows Task
> Manager, the process contributed to only 3% of CPU utilization.
>
>
> Does anyone know a better way to access a control from a
> backgroundwoker thread?
> Is it possible to create a delegate to a control?
>
> I am interested in a solution that allows me to continue to use the
> For ... Each statement to process and update the listview.
>
> Something like "For Each lvwItem In ListviewDelegate".
>
> I already know how to access individual list view items in the by
> using a delegate method. If I do that I will be forced to call the
> delegate method in the loop for every listview item I want to access.
> Also I will have to get the nubmer of listview items first and use the
> regular For ... Next in the loop instead.
>
> The reason I prefer the For ... Each loop is because I have a
> FileSystemWatcher process running in the background that will add or
> remove items from the listview control automatically. So if new items
> are added to the listview control during the For ... Each loop
> processing, they will also be included in the processing as long as
> the For ... Each loop has not finished.
>
> If there is no way to use For ... Each statement the way I would like,
> I guess I will need to figure out how to make the main form more
> responsive using my current approach.
>
> Any comments or suggestions would be appreciated.
>
> Thank you.
> Jason
>

On Fri, 09 Feb 2007 22:03:42 GMT, Spam Catcher
<(E-Mail Removed)> wrote:

>You only need to "invoke" when updating something on the form.
>
>Thus, if the majority of your background thread is looping, calculating,
>fetching data... then you can only call "invoke" when you update an element
>(i.e. set an item text property etc.).

Okay.

I ended up creating several methods which I invoke in my loop using
the main form's thread whenever I need to read, update, set item
color, and so on in the listview control. It looks messy but it
works.

Thanks for the suggestion.
Jason

On Sat, 10 Feb 2007 09:57:47 +0100, "Michel Posseth [MCP]"
<(E-Mail Removed)> wrote:

>
>Well this can be solved verry easy , just load the items in a array , data
>table , hashtable or whatever
>pefform your operations with the items in this .
>
>as last action you set them to the listview control for your user to see
>with a delagate

You approach would work for me except I have to change font colors on
certain items in the listview. Instead of creating another array to
keep track of item colors, I just invoke different methods in my loop
to set color directly on the listview.

Thanks for the suggestion though.
Jason

(E-Mail Removed) wrote in news:(E-Mail Removed):

> I ended up creating several methods which I invoke in my loop using
> the main form's thread whenever I need to read, update, set item
> color, and so on in the listview control. It looks messy but it
> works.

Ya - that's how it like :-(