WPF rapid CollectionChanged events blocking UI. Where & How to implement delayed update of CustomControl

I have created a somewhat complex CustomControl that, while optimized and threaded, still takes a nontrivial amount of time to update the UI after the bound collection changes.

I have this control bound to a DataGrid's SelectedItems collection.

Inherently the SelectedItems collection fires a CollectionChanged event for every individual item in the collection.

So, for example, the user drags the mouse to select 10 items which causes 10 CollectionChanged events to be fired in rapid succession.

This, in turn, causes my control to update 10 times in a row, which causes the UI to block.

To be clear, my control does do all of it's processing in a background thread, and is开发者_StackOverflow社区 optimized to do the minimum amount of work on the UI thread.

What is the correct way (or some options) to 'delay' the update of a control, so that rapid CollectionChanged events (or even databinding changes) cause the minimum number of updates?

Thank you kindly for your advice.

If you are handling CollectionChanged event of the SelectedItems of DataGrid then there is no escape sadly. :(

Although you can do one thing, dont update your custom control directly by subscribing to the CollectionChanged event of the DataGrid, use an intermediate publisher-subscriber queue pair which is DispatcherTimer based. The timer will publish its entries every 500 milliseocnds (slow for machine but seemingly fast for a user) then publish a single event every 500 milliseconds with all collection changed events together in those 500 milliseocnds (all e.NewItems and e.OldItems collected together).

The publisher timer will ONLY start ticking if it finds at least one collection changed entry which is yet not published.

Binding async may help. That way the rest of the UI is processed first.

    Text="{Binding Path=MyGabeLib.Search.SelectedDoc.DocTextDownloadFirstPage,
           IsAsync=True, FallbackValue=Waiting_For_Server, Mode=OneWay}" /> 

Also for expensive calculations I typically save the input and result and if the input does not change then I return the prior result as often the UI will sometimes make multiple calls to the get.