In the end I just went with a 3rd party control though

I too am looking for a proper solution to this problem, and thus far the best I have found is similar to Kenneth’s suggestion to use Timers. However, you are going to want to write code on your form which listens to the ListUpdate event and enable the timer only then, disabling it in the timer_OnTick method so that you are not letting the timer call the UI thread for no reason.

In addition, you’ll want to keep track of which rows have changed, and only force the UI to update those rows or if add/deletes have occured, refresh the entire grid.

In actuality, this creates a more streamlined GUI than if you have to Invoke over to the GUI every time a single cell changes.

Anyway, please let me know if you have come to any further conclusions about this issue.

-Eric

First, I’ve done passing a reference of the UI control to the IBindingList instance but that is bad as it does couple my UI too much to the data layer.

Instead the UI registers itself to a helper class. The IBindingList class checks the helper to see if a UI control exists and if so calls update on the UI thread.

This solution is neater, to me, as my data layer "engine" may be in a UI application. If so, then the IBindingList doesn’t find a registered UI control (and thread) to update on.

(And I am using XtraGrid, but I’m sure that’s unimportant).

The problem has always tricked developers to do all kinds of weird workarounds in order to avoid synchronization issues between threads and especially the UI.

If we look aside from all those kind of "spooky" workarounds I’ve made through time, I finally found a way that *always* works, and at the same time is extremely simple…

Use Timer(s) on the form to do all updates and get (synchonize) all "external" data from other processes and threads. The timer will always execute in the GUI thread, and there’s no circular events which in turns feed themself and so on. Always clear, clean and simple.

You can probably do more exact timing in your GUI by calling directly into (or triggering) it from external threads and so on, but you pay a high price in increased complexity (and sometimes performance as well). So let the UI handle all UI tasks and let it also decide when and how often to update itself. Ofcourse you should ensure all means of thread safety required when reading from the "external" data sources.

I’ve done a fair amoung of thread development over time, and as simple this "design" may look, as much I love it for saving my time and solving all those weird, and sometimes almost impossible to find bugs that comes along with a complex design involving synchronization between 30+ threads.

In other words, don’t trigger or call into the UI from your external threads. This way you always knows who is in control at any time, as many synchronization/thread issues is actually about who has responsability at which point in time.

The approach seems to introduce an enormous overhead and it has the requirement of instantiating the collections in the UI thread, which I think can be pretty difficult to comply with in real-world applications (or libraries/frameworks, even worse). I’m sure it would be a great deal easier to simply let the UI control itself do the work - after all, the requirement to run on the UI thread is a requirement introduced by the UI control in the first place, so it should have the responsibility of assuring that this is adhered to. Not to mention it’s simply the easiest way.

And finally, I can’t imagine Microsoft made their decision to NOT do this in their UI controls because they knew this Daniel guy would come up with his idea I’m not much closer to understanding why MS (specifically, but probably loads of other component writers) decided to go the way they did.

Hey, thanks for your comment - I certainly appreciate the pointer!

Anyway, this is all not the problem - I understand every tiny little bit about the original problem (and the solution) of synching into the UI thread. The thing I’m talking about is that if things are left to me as the programmer of a collection class (instead of the UI control programmer handling things), there’s really no way for me to do the job correctly, because the UI thread is simply something I’m not concerned with.

I found an article that has similar code to what I use http://www.windowsforms.net/articles/asyncbindinglist.aspx in your sample it will throw a null reference or thread error on exit only because there is no thread join / clean exit for the background thread.
Hope that helps.

John