一部のコンテキストでは、ListChangeListener で、リスト自体を制御せずに、「すべてのデータがスワップアウト」を検出する必要があります。選択などの状態をクリアする必要がある場合は、完全に新しいデータでは古い状態は無意味です。
によって完全に新しいデータに到達できます。
- list.setAll(...)
- list.set(otherObservableList) リストが ListProperty の場合
setAll でどのタイプの変更を発生させることができるかを考えます (c は変更、items は監視対象のリスト、サブ変更をカウントするための「subChangeCount」疑似コード):
// initially empty
assertEquals(0, items.size());
items.setAll(1, 2, 4);
assertEquals(1, c.subChangeCount());
assertTrue(c.wasAdded() && !c.wasReplaced());
assertEquals(0, c.getFrom());
assertEquals(c.getList().size(), c.getAddedSize());
// initially not empty
assertTrue(items.size() > 0);
items.setAll(1, 2, 4);
assertEquals(1, c.subChangeCount());
assertTrue(c.wasReplaced());
assertEquals(0, c.getFrom());
assertEquals(c.getList().size(), c.getAddedSize());
これにより、次のようなユーティリティチェックが可能になるようです:
boolean wasSetOrClearedAll(Change c) {
if (c.getList().isEmpty()) return true;
c.next();
if (c.getAddedSize() == c.getList().size()) return true;
return false;
}
対照的に、ComboBox のアイテムをリッスンする内部 fx コード、fi:
while (c.next()) {
comboBox.wasSetAllCalled = comboBox.previousItemCount == c.getRemovedSize();
...
}
comboBox.previousItemCount = getItemCount();
古い itemCount を格納し、それを現在の removedSize と比較します (これには不快感を覚えます。古い状態は、私の好みではあまりにも頻繁に古くなっています)。
質問は:
私のユーティリティメソッドはどのコンテキストで失敗しますか(そしてコアアプローチは setAll を正しく検出しますか)?