Question

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

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.