Skip to main content

Custom hierarchical cursors with the AdvancedDataGrid

· 2 min read

Yesterday, I was trying to write a custom hierarchical cursor class that implements the IHierarchicalCollectionViewCursor interface. But no matter what I tried, the AdvancedDataGrid would not recognise my implemented cursor class as being hierarchical. When I extended the HierarchicalCollectionViewCursor class, the AdvancedDataGrid would happily recognise it - even I overrode every single method and property... yet, as soon as I switched the class to implement IHierarchicalCollectionViewCursor instead of extending HierarchicalCollectionViewCursor the AdvancedDataGrid would break again.

Well, it didn't take me long to presume that the AdvancedDataGrid, or one of its related classes, was actually checking for an instance of the HierarchicalCollectionViewCursor class, and not the IHierarchicalCollectionViewCursor interface, as it should. So, a quick grep revealed that to be true. The AdvancedDataGrid.makeListData() function, to be specific, compares a private iterator's type to the HierarchicalCollectionViewCursor class, where it clearly should be comparing to the IHierarchicalCollectionViewCursor interface. So, a quick override, and problem solved :)

Here's what the overridden function looks like:

override protected function makeListData(
data:Object, uid:String, rowNum:int, columnNum:int,
):BaseListData {
var advancedDataGridListData:AdvancedDataGridListData =
as AdvancedDataGridListData;
if (iterator &&
iterator is IHierarchicalCollectionViewCursor &&
!(iterator is HierarchicalCollectionViewCursor) &&
columnNum == treeColumnIndex &&
!(data is AdvancedDataGridColumn) )
initListData(data, advancedDataGridListData);
return advancedDataGridListData;

It begins by calling the super version, but catches the special case where the iterator implements IHierarchicalCollectionViewCursor, but is not a HierarchicalCollectionViewCursor object (or descendant).

I've logged this bug over at - so you can track it's progress at