Hey,
Just a quick bug we noticed with the ModelViewViewModelPreview plugin, when you ViewModel creation type isn’t “CreateInstance” and can’t be automatically resolved you’re left with a nullptr ViewModel in the preview window which can’t be modified for previewing
In our project we generally default to Manual, as we’re conscious of the runtime overhead and possible memory fragmentation from every widget creating its own ViewModel that will just be immediately destroyed when we replace it with the live ViewModel instance (maybe irrationally but it’s not the point of this post)
This makes the ModelViewViewModelPreview plugin unusable for us, since it requires going through and updating all the ViewModel creation types to Automatic to use the preview tool, and then remembering to switch them back and not accidentally committing that change
I’ve got a PR here: https://github.com/EpicGames/UnrealEngine/pull/14095 which just creates a ViewModel instance in the WidgetPreview if one doesn’t already exist from widget construction
Would love if this PR (Or an alternate fix if necessary) could be added, just don’t want to maintain divergences
Thanks!
[Attachment Removed]
Hi,
I’d be a bit concerned about enabling this behavior by default, especially since it may violate some assumptions about certain things being available when the viewmodel is created. For example, my VM might have some logic that relies on things only present at runtime, and creating it automatically in the preview could lead to a confusing crash. I do think this could be useful as an optional feature of the widget preview, so perhaps an opt-in setting on the preview to find and initialize manual viewmodels would be a good compromise.
Best,
Cody
[Attachment Removed]
Hi,
It looks like one of our tools programmers is working on integrating that PR with the changes to make it optional. You should receive a notification through Github once that’s checked in so you can reconcile your local change.
Best,
Cody
[Attachment Removed]
Hey Cody
Yeah, that’s a fair call, not something I’d considered because it’s not a use case we have.
We’re pretty strict architecturally on the ViewModel containing all the data it needs for views to bind to, or to create functions from for the views to bind to.
We don’t allow ViewModels to ‘pull’ data in the way you’re describing, because it breaks the ability to create ‘mock’ ViewModels, which is very important for things like this preview tool, but also for creating things like tutorialized screens, where you’re mocking in whatever data you want to teach the user how something works. Or create snapshots of data to be used in UI later, like creating a ViewModel from a reward and queuing that to be shown to the player after the reward object has been destroyed
Would you like me to update the PR to be opt in, or are you happy to take that on?
[Attachment Removed]