Derp moment of the day...month...year?
Sometimes it's hard to describe the amount of facepaw that a simple coding error can cause. For the last two days I was hunting down an annoying bug in one of my larger pet projects. It caused the same component of code to work under one condition but not under the other.
More precisely, I had programmed a class to hold - amongst other things a list of certain items. This list is stored in a custom built collection. Adding items to the objects worked just fine, clearing the list however left the items in place in the user interface (WPF data binding). The items are "ranges" - i.e. x/y w/h rectangles - that should be superimposed over a bitmap to indicate "used areas" of an image. Once a new area was used, it showed up right then and there. But when refreshing the information from the database (i.e. clearing the list of areas) the old information just stuck there until the program got restarted.
After debugging and even single stepping over the code I finally found out just where the error was... It boils down to this little gem here - but of course all the parts were all over the place, hidden between about 1k likes of other code. Note that this isn't the exact code but rather a brief summary:
private UsedAreaCollection _Ranges;
public UsedAreaCollection UsedRanges
{
get
{
return _Ranges;
}
}
private List _UsedRanges;
public void Add(UsedArea newArea)
{
_Ranges.Add(newArea);
NotifyPropertyChanged("UsedRanges");
}
public void Refresh()
{
_UsedRanges = new List();
NotifyPropertyChanged("UsedRanges");
}
I was suspecting the data binding because I wrote a custom converter that created a BitmapSource object from the UsedAreaCollection and that was bound to the Source property of an Image. It actually works like a charm... but only when actually MODIFYING THE RIGHT COLLECTION.
This - again - is a good example of where unit testing could have pointed me to the right direction way ahead of time. Because then I would have realized that the actual property didn't change at all.
More precisely, I had programmed a class to hold - amongst other things a list of certain items. This list is stored in a custom built collection. Adding items to the objects worked just fine, clearing the list however left the items in place in the user interface (WPF data binding). The items are "ranges" - i.e. x/y w/h rectangles - that should be superimposed over a bitmap to indicate "used areas" of an image. Once a new area was used, it showed up right then and there. But when refreshing the information from the database (i.e. clearing the list of areas) the old information just stuck there until the program got restarted.
After debugging and even single stepping over the code I finally found out just where the error was... It boils down to this little gem here - but of course all the parts were all over the place, hidden between about 1k likes of other code. Note that this isn't the exact code but rather a brief summary:
private UsedAreaCollection _Ranges;
public UsedAreaCollection UsedRanges
{
get
{
return _Ranges;
}
}
private List _UsedRanges;
public void Add(UsedArea newArea)
{
_Ranges.Add(newArea);
NotifyPropertyChanged("UsedRanges");
}
public void Refresh()
{
_UsedRanges = new List();
NotifyPropertyChanged("UsedRanges");
}
I was suspecting the data binding because I wrote a custom converter that created a BitmapSource object from the UsedAreaCollection and that was bound to the Source property of an Image. It actually works like a charm... but only when actually MODIFYING THE RIGHT COLLECTION.
This - again - is a good example of where unit testing could have pointed me to the right direction way ahead of time. Because then I would have realized that the actual property didn't change at all.