I use world space widget UI dialogs that are assembled using widget components which themselves are customizable in the editor’s design view using instance editable properties. The properties are evaluated during PreConstruct and only aesthetically modify key child widget components.
The problem is, half the time when I reference a child widget component that was flagged as “isVariable” from the PreConstruct event, the reference throws the “Accessed None trying to read property” warning resulting in configuration failure.
As a workaround i’ve added a 100ms Delay node with an if that loops n times until the key child widget references return as valid. This seems like a poor solution to something that shouldn’t be an issue.
Why aren’t my child widget components which are added via the editors design view and flagged as isVariable not resolved by the editor before the editor calls PreConstruct? I’d use the Construct event instead, but they I loose the WYSIWYG design time capability.
This is bizarre behavior. I do tons of weird stuff in Pre Construct and never had this problem. I even set Events and dynamically create widgets and it all works fine.
Just to clarify, your screenshot is of a widget blueprint, correct? And when you say widget component, you actually just mean a widget, correct? A widget component is what you add to an actor.
Only thought I have is that maybe the “Accessed None” isn’t the widget itself, but a property on the widget?
Are you using a C++ base class? One time I had NativePreConstruct() that called Super::NativePreConstruct(). That calls my Blueprint, but the setup code in C++ only executed AFTER Super::NativePreConstruct() returns. So the blueprint would run BEFORE my C++ setup code. That meant that my member on the widget wasn’t allocated yet (ie. a material). So your delay would be letting the C++ NativePreConstruct() finish running and then the Blueprint can continue. IOW, the Super::NativePreConstruct() in C++ needs to be called at the end, not the start of your function. In your case, since you’re checking isValid, this could only happen if one of your variables was a C++ property set up in NativePreConstruct(), but the principle is the same and worth mentioning I think.
You are correct on both accounts, the BP is of a Widget which inherits from UserWidget and when i refer to a widget component, I’m referring to common and user created widgets (prefabs/templates) that are added as children to the main widget(s).
I don’t currently use C++ base classes for my widgets, however i have thought of doing so as a troubleshooting step. Good to know about the NativePreConstruct pitfall.
I do get errant behavior when my widget calls it’s parent’s PreConstruct before the branch, but i dropped the call to the parent UserWidget at some point during debugging. It’s weird intermittent behavior which makes it difficult to debug.
Well, I’m all out of ideas. This really shouldn’t be happening. Like I said, I do all sorts of weird things in PreConstruct and never ran into this. I’d go mad if this ever happened to me. Hopefully someone else can jump in and help you.
What I don’t understand is that all the widgets are supposed to be available when PreConstruct is called unless there’s another earlier call somewhere that destroys them (or is intended to do the setup). That’s why I mentioned the C++ NativePreConstruct() method. If you’re not using that, then something is destroying and recreating your widget. That’s doubly perplexing.
I’m still not convince the error is on one of your main variables. It could be a variable in one of those widgets. Are you accessing anything in those widgets that isn’t setup by their own PreConstruct graph and perhaps it’s setup later?
Dunno. Just throwing ideas out there. Either something is destroying your widgets and recreating them or your error isn’t on the widget variable, but rather a widget member (or subwidget) that isn’t created yet.
