Thank you for the quick response! I’m indeed wondering if I’m approaching this issue in the right way and I also don’t know how this (seemingly quite universal) problem is generally handled by UI libraries. As I see it, the main issue is that the UI must both reflect the internal state of the program, as well as manipulate that state based on user input, and both situations result in the variables of the UI component itself being changed, which in turn dispatches a change event.
Perhaps a scroll view would be a practical example of this? There is the view area that shows a part of some larger set of information (e.g. rows in a table), and then there is a Scroll component on the side. When the user pushes the up and down buttons or drags the thumb, the information visible in the component should change (e.g. the subset of rows that is shown), and I guess this should be done as response to the onChange event?
However, when the information is changed due to reasons other than user input (e.g. the table could receive new rows which are slowly generated by some internal process), the Scroll also needs to be updated, for example the max value needs to change if new items are added to the table.
If the component has an onChange handler, it will respond to user input, but it will also respond to the latter case of being updated due to an internal state change. For example, on receiving a new row, the component updates its table and its scroll bar’s max value, then the scroll bar dispatches a change event whose handler again updates the table, but after this the position should no longer change, I guess.
It just feels wrong to trigger such a bidirectional user interface event chain in response to an internal state change, and I’m wondering if some more complex use case could result in a longer back-and-forth loop? In any case, now that I’m writing this example, I also realize that I don’t actually know how the default HaxeUI ScrollView (and the ListView and TableView derived from it) handles this situation?