Tooltip binding conversion function called twice

GoJS
1

Hi,

I have a node which contains multiple items. For each of the items, I have a different tooltip, which is built using the function buildTooltipText.

When I hover over one if the items, this functions gets called twice, once for the node (with data = node.data) and once for the item (with data = node.data.values[i]).

I would expect that the function is called just once, only for the item, especially since the tooltip template is defined only for the item.

Sample code:

function buildTooltipText(data) {
    console.log(data);
    // ...
}

const TooltipTemplate = $(go.Adornment, 'Auto',
    $(go.TextBlock, new go.Binding('text', '', buildTooltipText))
);

const BarItemTemplate = $(go.Panel, 'Auto', {
        toolTip: TooltipTemplate
    },
    // + rectangle shape
);

const ChartTemplate = $(go.Node, 'Position', {
        itemTemplate: BarItemTemplate,
        layerName: 'Background',
        selectable: false,
    },
    new go.Binding('itemArray', 'values')
);

Another colleague has reproduced my issue based on the sample code above:

I’ve reproduced this issue in a minimal working example. When we bind toolTip’s text to some field like: new go.Binding('text, ‘tooltipText’) then it works correctly. Moreover I’ve tested other item’s properties like binding item’s alignment to empty string - it still works correctly. So for me binding toolTip’s text to empty string and resolving it via conversion function is rare edge case bug in GoJS. It should be reported probably to GoJS team

Best,
Lucian

2

Thanks for reporting this. We’ll investigate it.

3

Actually, the problem was even more obscure than that – the tooltip’s Adornment.data was temporarily being set to the Node.data and then being set correctly to the particular item data (Panel.data).

So the binding always got set correctly in the end – but in the meantime it briefly was being set to the wrong value. And that could be seen in a binding conversion function.

Thanks for reporting the problem and providing a precise reproducible case! The fix will be in 2.0.3, which I think should come out later this week.

4

That was fast! Thanks!