Can't interact with UI w/ thread processi

[Cotasm]

OK, this doesn't make much sense, but....

On my form_load I start a thread whose sole purpose is to allow me to see and interact with the form while the thread populates a listview with a lot of data.

If I do this...

-------------------
Private Sub frmMain_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.Load
Dim thd as new Thread(AddressOf PopulateListview)
thd.Start()
End Sub

Private Sub PopulateListview()
'populate listview code here
End Sub
-------------------

...then it allows me to interact with the UI without error while it populates the listview (I've tried this with other controls and recieved exceptions). YES, I am aware that I am not supposed to do this from a thread that the control wasn't created on. So, to make it reliable, I decided to do it the right way (I think)...

-------------------
Private Sub frmMain_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.Load
Dim thd as new Thread(AddressOf PopLV)
thd.Start()
End Sub

Private Sub PopLV()
BeginInvoke(New CtrlHandle(AddressOf PopulateListview))
End Sub

Private Delegate Sub CtrlHandle()

Private Sub PopulateListview()
'populate listview code here
End Sub
-------------------

...Now it works the same (making be feel better about working with the listview), but I cannot interact with the UI until the process is done. AND, whether the cursor is a pointer or hourglass is based on how I set the priority of the thread (and I've tried them all).

I'd like to be able to interact with the UI during the population process. Any help on this would be greatly appreciated!

[Edneeis]

I don't know that I would multithread the population of a listview since you have to actually create new listview objects to do so. Which means you break the rule of creating a control (or part of one) on a non-UI thread. You can get around this by marshalling back to the UI thread for the creation of the ListViewItem and then fill it in the alternate thread but all that marshalling may actually make the whole process longer instead of shorter.

I may be mistaken here, well it depends how you want to create the listviewitems. I was going to delete this post but thought it might be confusing if someone had already read it.

[Cotasm]

Edneeis, I'm glad you didn't delete your post... it did give me some ideas.

Any additional info or code samples are welcomed.

Thanks.

[Edneeis]

I'll try and do an example and post it later today.

[Cotasm]

Edneeis,
Thanks for offering to give me an example. I won't need it though, as I've been able to solve my problem.

You were right... the key was to use a loop in the working thread to gather the info for each ListViewItem and then call back to the main thread for each of those objects to be created (with your provided args) and added to the ListView.

I would provide my code, but it's rather complex. I will see if I can trim it down and post it for others.

Thanks again.

[Cotasm]

One last question on this topic...

If I do this in the main thread:

Public x as Hashtable 'global var

...and I do this in the working thread:

x = New Hashtable

...then technically, which thread was that object created on? And, is it safe to assume that no methods for this object should ever be called from the non-creating thread?

In other words, how strict must this rule be? Does the rule on not doing cross-thread calling apply to all objects, just GUI controls, etc?

Thanks!

[Edneeis]

A lot of it is going to come down to trial and error but I believe the primary problem is only with objects that have a UI as the problem is generally communication with the 'UI Thread'. Although you should take care to wrap any access calls to items shared across threads with a SyncLock block. If more than one thread trys to access the same resource at the sametime it is bad news. SyncLock manages this by blocking any second attempts until after the first is done.

[Cotasm]

Thanks, Edneeis!