MVVM bindings will sometimes get unset

Development Programming & Scripting UI
, ,
1

We are using the UMG View Model plugin, and rely on it extensively for our UI. Occasionally when we make changes to the widget hierarchy, the bindings get reset and an error prevents us from compiling. While the repro conditions are a bit nebulous, it’s easy enough to reproduce as we hit it consistently. Usually this happens when you duplicate an existing widget, rename it (usually for mobile), and fix up the blueprint so that it doesn’t throw errors.

`No binding found from an array of viewmodels to [Widget] -> [Property/Function]. Please add this binding or remove the Viewmodel extension on widget [Widget] from its details panel.`

OR

`setter name already exists and could not be autogenerated`

When we hit this error, the widget blueprint no longer compiles, even if the all the view bindings and widgets are set up properly. The only way to get around this is to restart the editor. After a restart this issue usually goes away.

This happens very frequently and is quite disruptive to our artists, who rely on rapid iteration via view bindings to test their work.

2

Hi,

We’ve also been experiencing this issue for a while (currently running on 5.4.2).

So I’ve decided to dig into it a bit myself and add more repro steps here for clarity.

Repro Steps:

  1. Create a new project and enable the ViewModel plugin.
  2. Create a new User Interface Widget Blueprint and open it.
  3. Add any ViewModel to the widget using the Viewmodels tab (the base MVVMViewModelBase will do).
  4. Add an Overlay to the widget and add a Text widget within that.
  5. Copy and paste the Text Widget to create a duplicate.
  6. Hit Compile at this point to check that the widget does in fact compile.
  7. Press Ctrl+Z to undo the widget duplication.
  8. Hit Compile and see that the widget does not compile anymore, with the error ‘The setter name X already exists and could not be autogenerated.’

Note that once you get into this state it’s difficult to get out of without restarting the editor.

You can reload the widget blueprint from the saved file state (even saving in this state is safe, because it’s only transient data that has gone wrong).

However I’ve found that reloading a widget blueprint in isolation can expose other problems with more complex setups, so restarting the editor is the safest course of action.

From debugging, what seems to be happening is that in FMVVMViewBlueprintCompiler::CreatePublicFunctionsDeclaration() each time we compile we are generating a new function graph for the viewmodel setter. These UEdGraph objects have the Widget Blueprint as their outer object and must be uniquely named across the other objects with that parent.

To accomplish this across subsequent compiles, the UMVVMBlueprintView holds onto these generated UEdGraph setters in the ‘TemporaryGraph’ member, then they can be reparented to the transient package before generating a new one and setting that in the TemporaryGraph for next time (effectively throwing the old one away).

However if the user uses undo, then before the recompile runs, the old setter UEdGraph (that was thrown away at the start of the previous compile) gets its state restored and is reparented back to the Widget Blueprint (so we effectively have 2 at that point). Then the one that was held onto in TemporaryGraph gets thrown away and we attempt to generate a new one, but this fails because we’ve already restored one (from 2 compiles ago!)

A workaround that I’ve found that seems to work is to ensure that the generated UEdGraphs are not serialised for undo/redo.

The graph gets recompiled after each undo/redo anyway, so it doesn’t seem necessary, however there may be a reason that they are instantiated as Transactional that I haven’t seen yet.

For this workaround, add this at line 1042 of MVVMViewBlueprintCompiler.cpp after UE::MVVM::FunctionGraphHelper::CreateIntermediateFunctionGraph() is called:

Setter.SetterGraph->ClearFlags(RF_Transactional);It would be great if we could get an official fix for this, as it’s an issue that our UI artists encounter often.

Thanks,

Dave

3

Hi,

Thank you for your inquiry. Regarding the error on viewmodel setters, it’s been fixed in the latest engine version by these two changes: Changelist 35582017 (github commit b761017), and Changelist 38296900 (github commit 07b9f45).

Regarding the other warning `No binding found from an array of viewmodels to [Widget] -> [Property/Function]. Please add this binding or remove the Viewmodel extension on widget [Widget] from its details panel.`, the message should point to the problematic widget (it should be a ListView derived widget). The viewmodel extension should be removed if it’s not used with the appropriate binding. From the details panel of the target widget, under List Entries category, select “Remove Viewmodel Extension”.

I hope this helps.

Zahra

4

I’m closing this ticket as Answered. Please don’t hesitate to reach out or re-open the issue if more support is needed.

Best Regards,

Zahra

5

This is great, thanks!

It looks like there are numerous improvements in this area in 5.6.0 (which we’re not taking for a while unfortunately!)

The change that I proposed above is contained within changelist 37804928 (github 2213c7f), so I think we might take that in isolation for now to solve the specific issue that we frequently encounter.

Thanks,

Dave