Concur with homembarata… But even with Tick you may see some timing issues…
I favor adding a Custom Event inside the Widget that you can call from Character.
Pass in a Bool value, or have a Bool already inside the Widget ready to be set etc…
Overall you risk losing time on these kinds of coding glitches, so a few suggestions:
Fix the problem for now using Event Tick inside the Widget (no Construct).
Add a Print-String to catch any ‘Cast Failed’ failure inside the Widget etc.
Hide / Show the Widget, instead of creating new instances on a Keypress.
(Store the Widget in a variable inside the Character, toggle Widget Visibility)…
Have the Character write a copy of the Bool to the Widget not refer back.
(Rule out another instance of the Character being spawned in the level etc).
5 .Swap the Bool for Enum / Int etc, as there’s many ways to mess bools up…
Overall, a Bool might seem like the easy option here. But the danger is, if the Bool-set code ever gets bypassed it may not be obvious. Whereas Enums are better (3). If you’re not familiar with Enums, you can just use Int: Set the default value of Key-Held to -1. Then you can tell inside the Widget if the variable was ever set and see if there are timing issues. Watch out using Get-Owning-Player-Pawn as well. If you spawn another player pawn, even by accident, or ever add Split-Screen, the object returned may not be what you expect. Overall, try using a Widget custom event for this. But if not, have the Character set an Int / Enum inside the Widget, rather than refer back to the Character. Also use restraint sticking code in Event Construct vs Tick / Custom-Events (fine for cosmetic work, not gameplay logic).