Illegal CrossThread Exception thrown when proccess is long

I didn't want to post this in the C# forum because the programs VB, so here it is...

I got a proccess thread thats in charge of loading a listbox full of the first line of text for richtextbox items. Though I use Me.Invoke(New MethodInvoker...) to add items on the main thread so its thread safe it coughs when large amounts of rtf data are thrown at it, acting as if I hadnt called adding the items on the main thread.

Up at the class level:
Dim Worker As System.Threading.Thread

In the load procedure for the form:
Worker = New System.Threading.Thread(AddressOf WorkerDo)
Worker.Start()

Private Sub WorkerDo()
Me.Invoke(New MethodInvoker(AddressOf FillList)
End Sub

Private Sub FillList()
For i As Integer = 0 To 'Upper index of collection of richtextbox controls
lstItems.Items.Add(RichTextBoxArray.Items(i).Lines (0))
Next
End Sub

List listItems is the list. I've tried creating a temporarily listbox in memory and than copy over the items to the desired listbox, but its getting stuck with the same exception even though the listbox has been created within the same subroutine (Filllist that is).

I admit I'm not too knowledgeable about pThreads yet, but I can't have it fill the list at the form's loading procedure because there are no items to put into the list until the task of loading up the RichTextBox array (also part of the pThread) has been finished. So right now I'm stuck at a dead end again...

Try the VB forum here.

what is the value of 'i' when it throws?

The value of i is 0, for the first index of the collection of rtboxes. The exception is thrown immediately on the first literation when it tries to add contents from index 0 to the list. I think I might be able to bypass this mess by using a timer, not ideal but if does the trick (wouldn't be the first time I had to use timers to get around limitations in .net :(). I'll go ahead and post this in the VB forums too when I get the chance. Just already registered here and the problem seems to be .net related rather than anything wrong with VB.

Well tried a SyncLock but even thats still throwing the exception....

Sigh.... Well with a timer I got it working, but if I try to select an item for example from the list on the form after it has loaded the same exception is being thrown :(

Dangit MS. Got rid of threading the app. Its working now but its time consuming and I don't get the advantage of a progress bar :(

Well thanks for the help everyone, but I think I'm going to need to make some major changes outside the scope of this topic...

What you need to be doing is using BeginInvoke on the control whose data you want to modify, so it calls a function, in its own thread, to modify the data. The reason you are getting that error is because you are trying to modify data in another thread, the thread that manages the GUI.

Google your exception and you will find how to do it in the first few results.

Me.Invoke invokes a no parameter subroutine on the main thread, so the adding of listbox items takes place on the main thread and works when the rtf data only contains plain text, but throws the exception if rtf data contains things like images.

I learned a lot about delegates today and decided to start using them to setup the form's controls. Problem now is, its still throwing the same exception on a control's invoke method. So what now I wonder....

BTW, how rude of me not post any code.

Here's the example:

Code:

---

private delegate void AddListBoxItemDelegate(object item);
private void AddListBoxItem(object item)
{   
if (this.listBox1.InvokeRequired)   
{
        // This is a worker thread so delegate the task.       
this.listBox1.Invoke(new AddListBoxItemDelegate(this.AddListBoxItem), item);   
}   
else   
{       
// This is the UI thread so perform the task.       
this.listBox1.Items.Add(item);   
}
}

---

Any other ways of calling the main thread to update a control anyone? I'm finding this more and more ridicuous as I go along here that I'm not having any problems with the application other than updating form controls.

I came across this the other day while searching for something else. I don't do VB but it might be worth a cheeky peek.

adeyblue, thank you for the link to that article

I can't guarantee it'll solve my problem (the circumstances are slightly different), but at least it helps me to understand some of the underhood non-sense in .net that can cause nightmares for the programmer.

Let me go ahead and expand on the actual program a little more. It has three esential forms, one for a startup form, one for editing the program's files, and another for using them (the purpose of having the program). These threading problems are occuring for the edit form which is accessed after the user has selected the file they want to edit from the startup form.

What makes my case different from the article? Well, the only default instance of any form in the application is the project's startup form. When a user wants to edit a file, a new instance of the edit form is created (the default instance isn't used). I also am getting an exception, while the author didn't on an invoke method that should have invoked on the thread the control is on (though through experimenting I was able to produce the bug described in the article before now).

Regardless of the differences, I'll take in the article's solution and see if it can help me. Hopefully it well, for the sake of getthing this non-sense over with so I concentrate on the actual program. Having to create a variable to the instance from the edit form itself? Who woulda thought of it? Well I guess thats .net for ya...

Well about 2 months later I'm still battling this. I've got another projet I've almost finished with and its only taken me 3 days. This project? Oh about 5 months. Its ridicously amazing how something seemingly so simple be so complicated. I've removed multithreading completely for updating GUI controls and got it only for loading the input file. Problem is, richtextbox contents are not being loaded and I'm getting control accessed from another thread than the one it was created on now. I'll post again here if I find a solution.