Evil Enumerations
-
Someone in a previous thread asked me why I was casting a LINQ enumerable into an array before using it...
public RecordList(IEnumerable<RecordView> en)
: base(en)
{
_idLookup.Clear();
int id;
foreach (RecordView rv in en)
if ((id = rv.BestID) > 0 && !_idLookup.ContainsKey(id))
_idLookup.Add(id, rv);}
(RecordList inherits from an ObservableCollection)
Model.PositionCollection = new RecordList(
DBInterface.Database.Provider.GetAllPositions().Select(a => new RecordView(a)));Looks nice and clean, right? WRONG. This was driving me so crazy that I started generating unique GUIDs for the RecordView objects to figure out why, for some reason, the RecordView objects being returned through the lookup (uses _idLookup) weren't the same ones that were actually IN the RecordList, and why updating one returned from the lookup wasn't passing change events to the view model... In fact, because of the way this RecordList is instantiated (Using a LINQ Select), _idLookup will NEVER contain the same objects that are in the collection itself, because that little Select() actually iterates twice... Once to run through the constructor, and then again to drop to the base constructor and actually populate the collection, yielding two distinct sets of objects... *grumbles and changes the constructor parameter to an array to make sure this NEVER happens again*
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
Someone in a previous thread asked me why I was casting a LINQ enumerable into an array before using it...
public RecordList(IEnumerable<RecordView> en)
: base(en)
{
_idLookup.Clear();
int id;
foreach (RecordView rv in en)
if ((id = rv.BestID) > 0 && !_idLookup.ContainsKey(id))
_idLookup.Add(id, rv);}
(RecordList inherits from an ObservableCollection)
Model.PositionCollection = new RecordList(
DBInterface.Database.Provider.GetAllPositions().Select(a => new RecordView(a)));Looks nice and clean, right? WRONG. This was driving me so crazy that I started generating unique GUIDs for the RecordView objects to figure out why, for some reason, the RecordView objects being returned through the lookup (uses _idLookup) weren't the same ones that were actually IN the RecordList, and why updating one returned from the lookup wasn't passing change events to the view model... In fact, because of the way this RecordList is instantiated (Using a LINQ Select), _idLookup will NEVER contain the same objects that are in the collection itself, because that little Select() actually iterates twice... Once to run through the constructor, and then again to drop to the base constructor and actually populate the collection, yielding two distinct sets of objects... *grumbles and changes the constructor parameter to an array to make sure this NEVER happens again*
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)... ooorrr... don't use Linq... :~
-
Someone in a previous thread asked me why I was casting a LINQ enumerable into an array before using it...
public RecordList(IEnumerable<RecordView> en)
: base(en)
{
_idLookup.Clear();
int id;
foreach (RecordView rv in en)
if ((id = rv.BestID) > 0 && !_idLookup.ContainsKey(id))
_idLookup.Add(id, rv);}
(RecordList inherits from an ObservableCollection)
Model.PositionCollection = new RecordList(
DBInterface.Database.Provider.GetAllPositions().Select(a => new RecordView(a)));Looks nice and clean, right? WRONG. This was driving me so crazy that I started generating unique GUIDs for the RecordView objects to figure out why, for some reason, the RecordView objects being returned through the lookup (uses _idLookup) weren't the same ones that were actually IN the RecordList, and why updating one returned from the lookup wasn't passing change events to the view model... In fact, because of the way this RecordList is instantiated (Using a LINQ Select), _idLookup will NEVER contain the same objects that are in the collection itself, because that little Select() actually iterates twice... Once to run through the constructor, and then again to drop to the base constructor and actually populate the collection, yielding two distinct sets of objects... *grumbles and changes the constructor parameter to an array to make sure this NEVER happens again*
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Calling ToArray will result in doubled memory usage. How about changing your constructor like this:
public RecordList(IEnumerable<RecordView> en)
: base(en)
{
_idLookup.Clear();
int id;
foreach (RecordView rv in this) //<- change is here
if ((id = rv.BestID) > 0 && !_idLookup.ContainsKey(id))
_idLookup.Add(id, rv);}
Why this works? Because the base constructor copies all elements into his internal list. Robert
-
Calling ToArray will result in doubled memory usage. How about changing your constructor like this:
public RecordList(IEnumerable<RecordView> en)
: base(en)
{
_idLookup.Clear();
int id;
foreach (RecordView rv in this) //<- change is here
if ((id = rv.BestID) > 0 && !_idLookup.ContainsKey(id))
_idLookup.Add(id, rv);}
Why this works? Because the base constructor copies all elements into his internal list. Robert
Hmm... Right, the collection would get filled up before the derived constructor gets called... Why didn't I think of that? Nice fix... Thanks.
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
... ooorrr... don't use Linq... :~