TreeGrid.getOpenIcon argument mismatch

[gedri]

Hi,

I recently updated our system from SmartClient v12.0 to v12.1 and I notice the method TreeGrid.getOpenIcon now gets as an argument a record number instead of the tree node.

I am wondering whether this is a deliberate change or a bug since the documentation still states it should get the TreeNode:

String [URL] TreeGrid.getOpenIcon (node) [Advanced]
	Get the appropriate open/close opener icon for a node. Returns null if showOpener is set to false. Parameters: node - type: TreeNode tree node in question Returns: type: String [URL] - URL for the icon to show the node's open state

In the meantime, I overcome this by fetching the node per the given recordNum like this, but I'd like to be sure this is the correct approach:

var node = this.data.getAllNodes()[recordNum];

Thanks

[Isomorphic]

So to clarify, you're saying the API still behaves as documented, but you've noticed that internal framework code now passes recordNum? So you didn't really overcome something, you just decided to change your code to call the API in the way that internal code calls it?

Internal framework code has been changed to pass recordNum because this is required for the new Tree.multiLinkTree feature. If you're not using that, you can still just pass a TreeNode.

[gedri]

Sorry - I should have clarified this.
I am not calling this API, but actually providing my own implementation for it in order to choose the icon dynamically.
So I guess my implementation should expect the passed argument to be either a record number or a TreeNode?

Thanks

[Isomorphic]

Ah, OK. So, if an API is merely documented in terms of what it returns we do not regard that as a supported override point. For a method to be validly overridden, the documentation would need more details, such as, when and how often it is called, and what specifically it affects. Otherwise, very common kinds of internal refactoring can break your override, such as optimizations that cause a method to called less often, or calling the logic from another context where widget state is not what you assumed, or calling the logic with certain parameters omitted for a completely different purpose.

An example would be: you assume you are called every redraw and your override depends on that, but we optimize the framework to call only if the record changes.

As far as sticking with a technically not supported approach, if you implement support for a recordNum param you should be fine and it's unlikely things will change further in the near future.

There are other ways of providing icons dynamically that wouldn't suffer from being technically unsupported, such as an override of TreeGrid.getIcon(), which is designed with overriding in mind, and explicitly mentions this. Just call Super() to get the default behavior for icons other than the openIcon.

[gedri]

Thank you for this explanation.