[4.17.2] How are ToolTips handled when the Widget that created them is DeHovered?

I create a tooltip, via the Tool Tip Text Bind function.
It seems to work quite cleanly, the tooltip appears when hovered and disappears when dehovered.

The problem is I don’t know how it disappears so I can’t track that event.
Ive tried using the Get Tool Tip Widget Node and checking it with an IsValid Node, and even IsHovered, and Get Visibility nodes.

According to the IsValid Node, the Tooltip starts out Invalid, as expected(because I haven’t hovered over the widget yet), and becomes valid once I hover over the widget. But once I dehover, the tooltip remains valid.

According to the IsHovered Node, the Tooltip is NEVER hovered.

According to the Get Visibility Node, the Tooltip is “Self Hit Invisible” even after I dehover the widget.

Yet visually the Tooltip disappears properly on dehover.

How do I track that event?

You can create a tooltip semi-manually:

invalid.PNG
The *ManuallyCreatedTooltip *will be valid for as long as it’s being referenced by the parent that is showing it. Its visibility is dictated by what you set its root Visibility to. If you set it to *Hidden/Collapsed, *it will never show because the toolip displaying logic most likely adds/removes it to/from the viewport instead.
[HR][/HR]
You can also go for more automation and simply bind a tooltip widget directly. In this case, you do not have to *Construct *it yourself (see above) and the reference is created automatically:

invalid.PNG

This tooltip is created when parent is constructed.

Strange, for me they’ve always been invalid as if they had a life of their own; whether they’re showing or not. Are you sure about that? I hooked up the validity to a tick node and it just spams invalid all the time despite working just fine. Both of those references are, in fact, invalid.

invalid.PNG
[HR][/HR]

That’s because you’re not hovering over the tooltip itself, you’re hovering over the widget that owns the tooltip.

The visibility defaults to what you set the root of the Tooltip widget to and can be overridden (2nd screenshot). Ideally, this should be set to *HitTestInvisible *since you usually do not want anything to interact with the tooltip. I believe they’re added to the viewport rather than have their visiblity state changed.
[HR][/HR]

Every CustomWidget you create has *OnMouseLeave *event that will fire when the cursor leaves the visible part of that widget.
[HR][/HR]
If you require even more granular control over the widgets (and their tooltips), you should look into writing your own tooltip logic - showing / hiding / referencing / removing / tracking position. OnMouseEnter/Leave and Tick would be then responsible for handling them. This will also give you a chance to implement animation and delay - you might have noticed that the tooltips pop up almost immediately and there’s no way (that I’m aware of) to adjust it. An animation event changing the visibilty state after .5s would solve that, for example.

I tested it quite a bit. I had a Print node spamming text when the ToolTip was valid in green and red when invalid.
The print text never turned red, even after dehover. Tho the tooltip still disappeared.

That said, I have since made two changes that, technically, solved my problem but did not really answer why it was happening.
1.
Assuming the Tooltip isn’t removed on dehover(based on above results), I set up an integer tracker to track when dehover occurs.(OnMouseEnter/Leave events weren’t working at the time, maybe for reasons in 2?) The integer tracker in the tooltip increments an integer in the widget that spawned it, and the widget that spawned it simply checks for when the tooltip stops incrementing said integer. This works because I noticed that even tho the Tooltip is still present, it stops ticking.
Using that integer tracker allowed me to do what I needed.

I need to switch between Input Modes for Game Input and UI Input on the fly, and I had a rather poor setup for it.
Ive since resolved that setup, and it might have fixed the dehover issue, but since I had already found the solution in 1, I have yet to test and confirm.

Another thing to note, is that this project was migrated from older versions of the game.