howto avoid massive notification in DataBinding

Question

Hi,

I guess it's quite a common problem in databinding scenarios. What do you usually do, if you are running a batch update and want to avoid that a propertychanged-dependend calculations/actions/whatever are executed for every single update?

The first thing which usually comes to my mind, is to either introduces a new boolean or unhook/hook the eventhandler, ...

What I don't like about this approaches is:

• they introduce new complexity (has to be maintained, ...)
• they are error prone, because you have to make sure that a suppressed notifications are sent afterwards

I'm wondering if somebody addressed this problem already in a more convenient way that is more easy to handle?

tia Martin

Edit: not to missunderstand me. I know about the things .NET provides like RaiseListChangedEvents from BindingList, ... They are all addressing the problem in more/less the same way as I described, but I'm searching for a different way which doesn't have to listed drawbacks. Maybe I'm on the wrong track, but I though I give it a try here...

Answer 1

What platform? The post makes me think .NET.

What is the underlying objects? For example, BindingList<T> as a source allows you to disable notifications by setting RaiseListChangedEvents to false while doing the update.

Other than that (or similar); yes, disconnect the binding during big updates

Answer 2

There isn't a single one-size-fits-all solution, unfortunately. I've applied or seen the following solutions:

1. There are two singals. One signal is emitted when the change comes from a user action, the other always fires. This allows to distinguish between changes in the UI and updates by code.

2. A boolean to protect code

3. The property event framework stops propagating events automatically when a value didn't really change.

4. A freeze/thaw method on the signal or the signal manager (i.e. the whole framework)

5. A way to merge signals into a single one. You can do N updates and they get collected into M signals where M <= N. If you change the same property 100 times, you still only get 1 signal.

6. Queuing of signals (instead of synchronous execution). The queuing code can then merge signals, too. I've used this with great success in an application that doesn't have a "Save" button. All changes are saved to the database as you make them. When you change a text, the changes are merged over a certain time (namely until the previous DB update returns) and then, they are committed as a single change.

7. An API to set several values at once; only a single signal is emitted.

8. The signal framework can send signals at different levels of granularity. Say you have a person with a name. When you change the name, you get two signals: One for the name change and one "instance field changed". So if you only care "has something changed", then you can hook into the instance instead of all the fields.

Answer 3

The easiest route to take is to use the BindingSource component for your data binding. Instead of binding your controls to a particular object (or IList), use that object as the DataSource for the BindingSource, then bind the controls to the BindingSource.

The BindingSource class has SuspendBinding() and ResumeBinding() functions.