What is safe to put in the Pre Construct event in UMG?

Or maybe a better question: What is prone to cause crashes by putting it in the Pre Construct event in UMG? Right now I’m using the Pre Construct event to set up styles for widgets and some localization stuff for custom widgets, for example a text widget with two text variables with two different languages and a master toggle boolean that switches between these languages. This seems to work fine.

I’m really just wondering how far you can go with the Pre Construct event and what kind of things are better suited for the Construct Event. The tooltip for the Pre Construct event says “cosmetic updates using locally owned data”, but what exactly does that mean? Maybe I shouldn’t be too worried since you can disable the event temporarily in the Editor Preferences anyway?

The engine already has localization built in, you don’t need to / shouldn’t hardcode a bunch of switches for each language, you should readup on our localization scraping system.

Locally owned - does all the data exist on the widget, or does it need to access external game systems to determine the state? If it needs to access anything external, don’t put it in pre-construct. If it does crash, you can always disable it in the editor preferences so you can open the asset and fix it, then re-enable it.

Good idea, thanks. It seems like Pre Construct is pretty solid, and I guess you don’t usually access something external for previews anyway. It’s really nice to have actual previews for things instead having a huge visual difference between the editor version and the version in the game, so thanks for that!

1 Like

Hey cyaoeu, do you mind elaborating where I can find this disable feature. I managed to have this happen to me and need to get into my widget BP to fix it. Currently it crashes. Thanks in adv.

In the editor preferences:

image

1 Like

Perfect. Thank you.