Table does not react to propertyset changes properly

[Marc Englund]

~Almost all selects, including tree, do not listen for property value changes in the container; if a property of a item is updated, the select is not repainted properly.

The only known bug is now in Table.

[Marc Englund]

Table does listen for changes, but lazy-loading row buffering causes the wrong rows to be listened to.

[Marc Englund]

[3671] fixes most issues, but needs to be thought trough: listeners are added and removed in paintContent(), which is really the wrong place, but seems to be the easiest and least error-prone place. Consider Table, that needs to attach listeners to a 'window' of rows in view and in cache; it figures out which rows to paint in paintContent(), which is then a convenient place to manage listeners. However, it's not obvious when to remove the listeners.

[Marc Englund]

Table still does not notice property set changes

[Marc Englund]

Table property set change status:

Table does actually listen for changes, but Table calls setVisibleColumns() internally (in setContainerDataSource()), so new properties (columns) are actually hidden. This is wrong. If the programmer has not called setVisibleColumns(), all columns should be shown.

Table can not internally modify visibleColumns, and must paint all columns if visibleColumns is not set!

[Matti Tahvonen]

in [3973]

In the code newly added container property was added to visible column list, but change event (where cache building reacted) -removed- too late. Now adding to visible list first, then add property. IScrollTable needed a bunch of changes to support this properly.

[Joonas Lehtinen]

Milestone User Interface Library 5.1.2 deleted