ok, so this means you will fix the bug? It’s still in 4.7.4.
Will you fix it or will you not fix it?
Hello ,
To be more clear, I looked over the status of the issue and it has been changed to resolved internally and this solution should be available in a later release of the engine. I hope this answers your question.
Yes, it answers my question 
Could you also tell me whether there is the possibility for this to be included in something like a 4.7.5 hotfix? And if not, will a “later release” be 4.8?
Hello ,
There is no exact time frame in place for the implementation of this solution.
If you can’t tell when ths will be fixed, is there something like a workaround for this?
I am using the widget A as my main UMG widget which is drawn in the viewport. This widget B inside of widget A uses the “Get Owning Player Pawn” function and casts the Player to my own Player. My Player of course references it’s Player Controller, and in the Player Controller I have a reference to widget A since this is the place where I add the widget A to the viewport.
I’m still on 4.5.1 which is less picky about circular references involving UMG, but I’ve been gradually refactoring my blueprints to get rid of circular dependencies before trying to upgrade to a newer version, so I can give you some advice about it.
First thing is that most cases of circular dependencies are born from code that is too tightly coupled. While I agree UE4 should not break under tightly coupled code and I’m glad they are working on it, your project (and sanity) can only benefit from loosely coupled code design. It makes it much easier to plug/unplug things and makes it easier to reuse blueprints across different projects.
Event dispatchers are a great way of decoupling your blueprints without the need for laboriously wrapping everything behind interfaces. They also have the bonus of making it very easy to add functionality without bloating your blueprints.
You can use a shared actor/object that contains the event dispatchers and can be accessed by your other classes. It’s crucial that the dispatcher class doesn’t have references to any other of your classes, so it doesn’t depend on any class other than itself. This includes event dispatcher parameter types.
In your case, instead of having your PlayerController class create the WidgetA, you have it call a dispatcher on the “SharedDispatcher” informing that the playerController has been spawned (or whatever event it is that needs WidgetA to be displayed).
Now, you need to move the WidgetA spawning code to somewhere else. This needs to be a blueprint that is guaranteed to not cause a circular reference. The best options are either your level blueprint or an Actor-derived class that is placed on your level. There you bind a custom event to the SharedDispatcher “PlayerControlledSpawned” dispatcher, which creates WidgetA and adds it to the viewport. Since none of your custom classes will reference this blueprint, you’re free to do other tasks here with zero risk of circular dependencies.