Phew, last night I killed a bug in CaseDetective 2.0 in less than 30 minutes of development that had been bugging me (pun intended) for well over 4 weeks!
And what’s more, 30 minutes later after re-activating another feature that I’d disabled because I had a bug in that code that had also been bugging me for well over 4 weeks was also fixed, without me making any further changes!
I hate (love) it when that happens! 
The annoying thing is, my code for the first feature is virtually the same as before last night’s edits, I’d almost got the bug fixed before in that I’d whittled it down to a very specific block of code that I could hard-code around to get the results I wanted, but couldn’t get the proper solution to work, even though it looked absolutely right. I worked and worked on the area, making sure I fully understood the all the properties and events of the classes involved, but alas the solution failed to reveal itself.
Out of frustration I switched one parameter to a function that should have absolutely no effect from “true” to “false”, fully expecting that the problem still existed. It fixed the problem. Fantastic! But also very very annoying. I can only assume it’s either a very subtle bug in the framework, or more likely me not quite fully understanding the event interactions of a couple of classes.
I tell you, it feels great to have fixed these two problems, they were two great weights stopping me from progressing in important areas of CaseDetective, and stopped me from being able to efficiently concentrate on my work.
A great weight has been lifted off my shoulders, full steam ahead!
Still working with Flex? Can you give us more details about what went wrong?
Posted by Michael Sica on December 5th, 2007.
Hi Michael,
Yep, still using Flex.
I was saving off the Sort for an AdvancedDataGrid’s ArrayCollection data provider to a SharedObject, and when I read it back in I was constructing an array of SortFields to stuff back in a new Sort and apply to the AdvancedDataGrid’s data provider before getting the data.
The problem was that the AdvancedDataGrid was showing the correct fields as being sorted in the correct direction but were always sorted ascending, even if the direction should have been descending. Clicking the header to change the direction had no effect on the data, but the header changed accordingly.
I got close to solving the problem by removing the compareFunction from the Sort I was constructing at startup, but that meant numeric, date and compound columns were always sorted alphabetically instead of numerically, by date or through the two or more data fields that made up the column respectively. But at least it was sorting in the right direction and the direction could be changed correctly. This was definitely my fault, I shouldn’t have used the custom compareFunction because I dynamically add a sortCompareFunction to any AdvancedDataGridColumn that needs it when adding the user’s preferred columns to the AdvancedDataGrid, so I didn’t need to reference another custom compare function on the data provider.
But why wasn’t the AdvancedDataGrid using it’s column’s sortCompareFunction definitions?
When I created the SortFields for the initial sort I was setting the ignore case property to true just as a means of getting to the descending parameter that I was truly interested in, when I set that to false, suddenly the AdvancedDataGrid was using the correct sortCompareFunctions for it’s columns. Very strange.
On reflection, it could be that the framework is assuming that if the SortField has it’s ignore case property set to true then it must need to do an alphabetic sort, regardless of whether there’s a custom compare function on the column or not.
You did ask!
Posted by ianmjones on December 5th, 2007.