18

一部のコンテキストでは、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 を正しく検出しますか)?

4

1 に答える 1