Hi!
I have an UMG widget (let’s call it Widget 1) who has another widget (Widget 2) inside it. The thing is, when I press buttons in Widget 2, I need to access methods present in Widget 1 (for example, swapping Widget 2 with another widget or changing visibilities in Widget 1), and if I pass a Widget 1 type variable to Widget 2, then I fall into a circular reference problem (compiling Widget 1 uncompiles Widget 2 and viceversa).
How you would go about it?
Thanks in advance.
So I ran into this before and talked to our UI team about what is happening. You can run the game and have an “uncompiled” blueprint without any issues, because the blueprint was actually compiled after all of the changes were made. The “uncompiled” issue arises because compiling one changes a variable in itself that the other is looking at, so the observing blueprint thinks that it has also changed.
The solution is to just compile them both once, let one be “uncompiled” and use that blueprint anyway. It won’t hurt anything, it’s just percieving itself as being changed and therefor not compiled (even though it is). Let me know if that does not help or if you have any questions.
Thanks for your response, !
I am avoiding those circular references like the plague in my whole project (I have read a lot of horror stories about projects crashing and causing heaps of lost work), because I don’t want to risk having to rethink my whole structure down the road. Is it absolutely fine then to have a Widget 1 who has a Widget 2 inside it, and this Widget 2 having a Widget 1 variable for reference? If so, it would help me a lot.
Is it also true with standard Blueprint classes?
Our UI team intends for UMG to work like that. If it does give you any trouble, please make a bug report in answerhub so that I may assign it to them for reproduction.
In some cases you can have a loop like that, not compile and it works fine. It’s sort of context sensitive to what is communicating in what way, but if you do have a problem, let us know so we can address it.
Thank you again :). I’ll try it like this.
I make circular references a lot. Tonight when I was working on a new prototype, I made a blueprint that spawns blueprints and before the spawned blueprints get destroyed, calls a function in the spawner to say “hey it’s cool if you want to spawn another one”. I personally don’t worry about them to much and haven’t had any problems. One tip I can give though is make sure that all the blueprints in a circular reference system all save. If one breaks so do all the others, which is most likely the horror stories you’ve heard. 
It’s very useful to know that, pattym, so thank you :). I will try to avoid them as a basis but will keep in mind that they aren’t such “no-nos”. In my case, it’s about a HUD widget which has an options menu inside it.
Well, bad news. I had begun using circular references when the update hit and I bumped into the REINST bug (reclassed a ton of my widgets to some non-existing class and crashed the editor every time I attempted to remove or just click on one) which has made me lose a day’s work (and thank God for backups) and is caused, or so I have read, by circular references.
I’ll have to think of another way to go about this it seems :/.
Edit: Found this thread questions/129259/bug451-reinst-in-umg-reference-lost.html about using events for this kind of thing. Leaving it here in case it helps someone other than me.