Community
Participate
Working Groups
Change events aren't fired with a level of organization that I would prefer at the moment. Features that would be useful: 1. Breadth First event firing with child event processing queued until the parent level is processed. 2. Unit of work event aggregation allowing a listener to receive the collection of all change events triggered by the root change event. 3. Event sumation where a listener could register to care about A or B and would receive only one event if both A and B change.
Are we talking about an IObservable version of Control.setRedraw()?
No. We are talking about situations where the bindings form a graph, not a tree. Consider: List<Customer> --> selection -->> --> city. <---! --> state <--! --> zip ------+ When the user selects the zip, that sets city and state. But when the user sets the selection, unpredictable things happen because we have no idea of the order thar the change events will be fired.
