Hello, I have a problem with UMG. The Event from first picture receives data from a DT, I checked it at every single Pin, the Data is definitely incoming and the variables get definitely setted (sry for my bad english).
On the second and third screen you will notice that I bound the incoming data to my elements.
On the last screen, you see the result. Nothing is shown. Is it a bug, or do you see my fault?
As a test, could you Remove the binding from the Text Block, expose it as variable and set its text directly like so:
Btw, your blueprint looks good, I’m just trying to establish what else could be happening. Perhaps something else is overriding those variables on Tick. Let me know if setting the text block’s text directly produces anything in the widget during run-time.
If the screenshot you posted is with the binding removed, the issue lays elsewhere; could you show the blueprint responsible for creating and adding the widget to the viewport or canvas, the widget reference and how you use it to fire GetItem custom event?
At the moment I’m thinking that you might be creating more than one widget and send the data to a widget that we cannot see.
In addition, if you want to do some digging yourself:
Hook up a GetAllWidgetsOfClass node to a Tick in any non-widget blueprint, like a PlayerController for example, and see how long the returned array is.
btw Thx for your support. The first pic shows where the event is firing into the widget,
and the second picture shows where the “interact” input is coming from. (Its like a Key-Hold-Down-for-x-Time-Script).
Yes you’re right, I’m “creating” the
widget in my Item BP but also in
Player Controller and Game State to
get a reference to it (because some
events I need from the widget to
change something in the GameState and
some Control Input Issues I need to
control in the Playercontroller.
If you create a widget 3 times, you may end up with 3 separate instances of the widget and send the data to the referenced one that is not in the viewport, for example. Ideally, you should create a widget once, store its reference in an easily accessible location (like game mode or player controller) and show/hide only.
If I were you, I’d try the bit I mentioned first:
In addition, if you want to do some
digging yourself: Hook up a
GetAllWidgetsOfClass node to a Tick in
any non-widget blueprint, like a
PlayerController for example, and see
how long the returned array is.
Yes you’re right, I’m “creating” the widget in my Item BP but also in Player Controller and Game State to get a reference to it (because some events I need from the widget to change something in the GameState and some Control Input Issues I need to control in the Playercontroller.!
In Player Controller I’m adding The Widget to the Viewport. The Event is coming from the Item-BP.
I’m little bit confused, is it something what one better should avoid?
Or is there a more elegant way to get a reference to one Widget in different classes?
I removed the Create Widget Nodes in GameState and Item BP (Because My Widget is created and added to Viewport by Player Controller), And I replaced the removed nodes with the “Get all Widgets of Class” Nodes, looped and variabled them.
So my conclusion for all people with the same issue: NEVER Create more than one Widget. (I think the safer way is, to add another widget only, when the current one is removed).
No, no, you definitely do NOT NEED GetAllWidgetOfClass - I just suggested you used it for debug purposes only - to see how many widgets are created at run time.
If you organise your code right, you will never need that node. Create your widget once, reference it in a location all blueprints can access and use that reference from anywhere in your project to update the widget.
Imagine a situation where you still accidentally create more than one widget, and overwrite its reference in a loop like you do now. You still end up with an orphaned one that will need to be Garbage Collected. While everything may work fine, it’s just a bit sloppy and potentially dangerous. In a bigger project, something like that will cause a headache.