[RESOLVED] Too much for the UI thread to handle

[chris128]

I've got a form that acts as a progress report for a long running operation, it has a listview on it (which I might be replacing with a DGV soon) that gets updated with progress updates from a background thread that is doing all the work. The method running on the background thread raises events that the form then handles and adds the string passed in to this event to the listview. The method running on the background thread raises progress update events several times a second and for each of these updates the event handler on the form must invoke a method on the UI thread to actually add the item to the listview.

This works fine on my test PC (which has a quad core CPU and 8 GB of RAM) but others have reported that after a while the form goes to the Not Responding state so I'm assuming all of these updates on the UI thread are being requested too often for it to be able to process them all as well as user input.

So I'm looking for a better solution and have come up with the following:
When the background thread raises these progress updated events, instead of them being added to the listview instantly I add them to a Queue(Of String). Then every second the form would check this queue and remove any items currently in it and add them to the listview - using a Queue(Of T) instead of a List(Of T) should guarantee they come out in the correct order. Both of these operations (adding to the queue and reading/removing from it) would be done under a SyncLock block that would lock on the same object to avoid both threads trying to work with the queue at the same time, so there would still be some contention but I'm hoping it would mean the UI thread only gets busy once a second instead of potentially roughly 30 times a second as it is doing now.

Does that sound like a good plan? Can anyone think of a better way of handling this?

Cheers
Chris