[Dev] Problem with collection notifications
john at osafoundation.org
Mon Sep 26 09:03:57 PDT 2005
Phillip J. Eby wrote:
> At 09:13 PM 9/25/2005 -0700, Ted Leung wrote:
>> On Sep 24, 2005, at 3:07 PM, John Anderson wrote:
>>> Yes in some cases we don't want any notifications. Consider this case:
>>> wxWidgets handles the click, updates the selection on the screen and
>>> tells us about the change. As a result we store the change in the
>>> selection. The selection is a change to data that causes a
>>> which causes a new unnecessary update to the screen. So typically when
>>> the system updates the screen we only need to save the change. When
>>> data changes as a result of something the system can't handle we want
>>> notifications so we can update the screen. There are many other
>>> examples like this that crop up in practice.
>> It sounds like things like the selection should not be subscribing to
>> In general, I don't see a way to solve this problem without building
>> UI knowledge
>> into the notification mechanism.
> Well, you can disable notifications *during* notifications. That's
> the simplest way to avoid cascading. In point-to-point subscription
> systems (like peak.events), you can also use the trick of removing the
> current callback from the subscriber list when calling it, so other
> subscribers will see events generated by that callback, but the
> callback itself cannot receive events that it generates itself.
I tried to disable notifications during notifications, however this only
works with our synchronous notifications, not our asynchronous ones --
which is the problem I first raised.
More information about the Dev