Cross-thread operation not valid questions

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

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 "lvwFileLis t" and two buttons control to start and stops
a background process.
2) The backgroun process is done using the BackgroundWorkd er control
and it calls a procedure named "ProcessFileLis t" 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 BackgroundWorke r thread will result in a
"Cross-thread operation not valid"" error when the procedure attempts
to access "lvwFileLis t".

My next revision of the procedure uses methdodinvoke to get around the
"cross-thread" error:
Private Sub ProcessFileList
If Me.InvokeRequir ed Then
Me.Invoke(New MethodInvoker(A ddressOf 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.Doe vents() into the loop. But even with
Application.Doe vents 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 ListviewDelegat e".

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
FileSystemWatch er 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

>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

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.