Hi folks! I’ve been tinkering with a custom dialogue system, and I made the above editor utility widget (EUW) to preview what dialogue scenes will look like without having to fire up the game and click through dialogue. One of the features I want in this EUW is the ability to accept designer / developer text input to search through data table rows.
There’s only 2 widgets that are important here. The EUW shown above, and the search result row widgets that I’m creating dynamically in response to changes to the search string:
I know I could probably do this using event dispatchers or blueprint interfaces. But I have no clue why this method isn’t working even though I’ve gotten reference based function calls to work for other classes. So I want to figure out what information I’m missing here that’s making this fail.
Please if anyone has any insight on this, I’d really appreciate some enlightenment. I’ve searched around the forums and I’ve tried using AI assistance but I haven’t found any solutions or any description of the underlying obstacle that’s preventing me from just dragging the EUW’s function on the the WBP’s event graph. Please let me know if any other information is needed from me.
For editor utility widgets the usual culprit is the Call in Editor flag: a function on an EUW is only callable from other editor utilities if you open the parent function and tick Call in Editor (checkbox in the function’s advanced details). BlueprintCallable alone isn’t enough in the editor world — without that flag the function won’t even show up when you pull off the parent reference.
Second thing to check: the parent reference is actually set before the child uses it. If the row widgets are created with Create Widget inside the EUW, pass the parent through an Expose on Spawn variable on the row widget class and set it on the Create Widget node. If the reference is only assigned later, the call fires on a null reference and fails silently.
If both are done and it still won’t connect: make sure the variable type is the parent EUW class itself, not generic UserWidget — dragging off a UserWidget-typed variable only exposes UserWidget functions, not your EUW’s.
As far as I can tell, all of these recommendations are already in effect, but the issue still persists.
Picture 7 (last one) shows that the Call in Editor checkbox is checked for the parent widget’s function.
Picture 5 shows that the child’s reference is Instance Editable and is Exposed On Spawn while Picture 4 shows that the parent is supplying the child with a reference to self upon construction.
Picture 5 shows that the child’s reference of the parent is of the type EUW_DialogueScreenPreview
Sorry if I’m misinterpreting either your message or the indicators in my screenshots, I’m still kind of new to this.
No worries at all — you’re not misinterpreting anything. Looking at the screenshots you described, it sounds like you already have all three of those things set up correctly.
So I wouldn’t keep chasing Call in Editor, Expose on Spawn, or the variable type at this point.
The next thing I’d test is whether the reference is actually valid at the moment the child button is clicked. The type being EUW_DialogueScreenPreview tells Blueprint what the reference should point to, but it doesn’t guarantee that the reference is still pointing to a live EUW instance.
As a quick test, in the child widget, put:
Parent EUW Reference → Is Valid
and, if valid, print something from the parent (or just print "Parent valid").
I’d also make a completely trivial function on the EUW, e.g. TestFromChild, with Call in Editor enabled, that only prints "CHILD CALLED PARENT". Then try calling that from the child reference.
That gives us a useful distinction:
The function doesn’t appear when dragging from the reference → Blueprint/type/editor-context issue.
The function appears and the node executes, but the reference is invalid → lifetime/reference issue.
The reference is valid and the call executes, but the EUW doesn’t respond → then we’re looking at something specific to how EUWs handle editor execution.
If you can show the result of the Is Valid test and whether a simple TestFromChild function can be called, I think we can narrow down the actual obstacle rather than throwing more generic Blueprint suggestions at it.
I should have noticed the em dashes in ShadowBr0kerz’s first response. Their solutions don’t work. If anyone else has any personal insight on this problem, or has an AI agent automating their account except with more productive answers, I’m all ears.
That’s odd. I use this pattern all the time for UI lists. Everything looks good as far as i can tell. Do any other functions show up when you drag off the reference?
Another option is to get the Outer, cast it to EUW_DialogueScreenPreview and see if you can call it there. Probably the same results but unsure here.
In the last couple of days I’ve kinda moved on from here. I just used a Blueprint Interface implemented by EUW_DialogueScreenPreview to permit the child to call the parent’s functions. Now it’s not so easy to test stuff in the project I originally screenshotted when I created this thread. But I’ve managed to reproduce the issue in a blank project I created to explore this a bit more! I have learned a little bit, but I still don’t know what’s going on with UE to cause this to happen. I think it has to do with the fact that I’m trying to call functions via an EUW reference in a WBP’s class definition and for some reason Unreal Engine doesn’t allow this.
My test project doesn’t have anything in it besides 2 EUWs (representing parent and child objects), and 2 WBPs (same thing). (pic 1)
The original post didn’t have anything to do with in game UI, but I wanted to see if the observed behavior was any different for WBPs vs EUWs, and turns out it is. The child widget can call functions of the WBP by reference like I would expect. (pic 4)
Other functions do in fact show up for these attempts (pic 7), and I can even get & set variables for the EUW object (pic 8), but functions that I created aren’t shown for some reason.
It’s worth noting that I’m on UE 5.7.4 while doing all this which is far from the most up to date version at the time of writing. It kinda seems like a bug to me, so maybe this has been fixed in later versions? Unless there’s some kind of best practice or industry standard that I’m unaware of that would render this moot because this is somehow a desired behavior for other use cases.
I didn’t know that was a thing. I’m assuming it’s to prevent run-time dependencies on the editor only blutility classes, but what a pain to troubleshoot if you don’t know! I think your current implementation thru the interface is the correct way in this case. Thanks for updating!
sure
