Rocko Bonaparte
Topic Author
Posts: 39
Joined: 13 Oct 2020, 08:32

Adjusting to new NoesisGUI release for Unity

25 Sep 2022, 08:57

I returned to my actual Unity project to make updates. It was running on one of the 2019 releases and I moved up to 2021. In the process, I updated NoesisGUI inside of it as well.

I have quite the pile of errors but I think it comes down to two categories:
1. Not resolving Xamls (again)
2. Constructor code getting run that previously didn't expect to run until game mode.

I went from Unity 2019.3.7f1 to 2021.3.10f1. Noesis is at 3.1.5. I can't find an easy way to see what I had beforehand. I think it was 3.0.8?

1. Not resolving Xamls (again)

Previously I had this:
		private void InitializeComponent()
		{
			var xaml = UnityEngine.Resources.Load<NoesisXaml>("UI/wpf/mainmenu/MainWindow");
			xaml.LoadComponent(this);        // Compilation error

			//Noesis.GUI.LoadComponent(this, "Assets/Project/UI/wpf/mainmenu/MainWindow.xaml");
		}

Me using LoadComponent is an issue from a previous time and I guess it's now time to figure it out. Under my Unity project, the .xaml is indeed at Assets/Project/UI/wpf/mainmenu/MainWindow.xaml. The compiled asset is in Assets/Resources/UI/wpf/mainmenu/Top/MainWindow.asset; the convention for loading resources is to reference relative to the resource folder, not the root project folder. I never figured out why the Noesis.GUI.LoadComponent() call couldn't resolve the path. It lands in Noesis' own native code that I cannot step into so I don't know what its logic is for resolving these paths. Can somebody explain what I am actually supposed to feed it and how I could maybe get some diagnostics for the path resolution?

Going back to trying to use xaml.LoadComponent leads to a compilation error since that method is gone. I alternately found NoesisUnity.LoadComponent(this) to replace it, but that just causes Unity to crash hard.

I did see in the upgrade instructions that I shouldn't have to put compiled xamls in the resources folder. That's cool but I can't seem to get around it yet.

2. Constructor code getting run that previously didn't expect to run until game mode
Maybe the more fundamental problem are these build errors I get in my constructors off of my controllers. Stuff like this:
    /// <summary>
    /// Interaction logic for FullMainMenuNavigation.xaml
    /// </summary>
    public partial class FullGameMenuControl : UserControl
    {
        public GameMenuNavigationViewModel ViewModel;

        public FullGameMenuControl()
        {
#if NOESIS
            ViewModel = new GameMenuNavigationViewModel();
            this.DataContext = ViewModel;
#endif
            InitializeComponent();
        }
It looks like the Noesis package now actually tries to compile all that when processing assets. This is kind of a problem because some layers down, I am have some code that previously assumed it was happening in game mode that are just null references in the editor. That stuff shouldn't be running yet. Is this a goof on a poor assumption I made previously? Or did the convention on all this actually change? How do I keep that code for being run when the assets are getting initially loaded into the editor?

BTW, I do wonder if these problems are causes the assets to fail to load, so maybe fixing #2 fixes #1. I can hope.
 
Rocko Bonaparte
Topic Author
Posts: 39
Joined: 13 Oct 2020, 08:32

Re: Adjusting to new NoesisGUI release for Unity

26 Sep 2022, 07:53

I think some of the issue with resolving .xaml files is that they were trying to get loaded at run time as Resources, and I think that's just downright impossible now. At least I couldn't never get it to go. I did a lot of rearranging and I got rid of most of them, but I have this one nasty one.

I have converted a ScriptableObject that was previously instantiated and added at run time, which would get a handle to the main menu the kicks off most of my GUI logic. I had to change this to a MonoBehaviour that I pair to an object, and that MonoBehaviour references my main menu asset. I've reimported all my assets and don't get errors from this asset. However, when I run in game mode and try to bring up the main menu, I get an error about not finding ../Theme.xaml, which is a resource it references in its .xaml file.

The asset isn't marked as loaded when I check it in a debugger, and when I first initialize it, I disable the NoesisView that would show it (since I don't want the main menu showing yet). When I enable the view, it then tries to load it. Since this load is happening at run time, it can't locate any .xaml files any more.

So in short I am not resolving a .xaml dependency of another .xaml. The root one seems to resolve beforehand since I get an asset for it I can use. What am I supposed to be doing here?
 
Rocko Bonaparte
Topic Author
Posts: 39
Joined: 13 Oct 2020, 08:32

Re: Adjusting to new NoesisGUI release for Unity

26 Sep 2022, 10:02

Rereading the release/upgrade notes, I guess I didn't have to abandon using Resource .xamls completely; I just needed to remove the .asset files. Is that right?

I also have concluded that what I'm fighting here is most likely what I was fighting over a year ago or so when I was first integrating this stuff in the first place. I think it was the same issue where there was some temporality problem with initialization that was causing views to try to load their Xamls at unexpected times.

I'm guessing I also have to delete the .assets from the rest of my project and not just from the Resources folder. I think I cleared one error by doing that (and replacing the references with the actual .xaml).
 
User avatar
jsantos
Site Admin
Posts: 3545
Joined: 20 Jan 2012, 17:18
Contact:

Re: Adjusting to new NoesisGUI release for Unity

26 Sep 2022, 18:04

Thanks for coming back! :)
Rereading the release/upgrade notes, I guess I didn't have to abandon using Resource .xamls completely; I just needed to remove the .asset files. Is that right?
We don't recommend using Resources. Just let Noesis discover the assets that are being used and Unity will include them in your standalone. If you are creating the UI by code instead of using XAMLs then you need to include references to the needed assets using MonoBehaviour properties. If you don't do that, resources will be missing in standalone.
I'm guessing I also have to delete the .assets from the rest of my project and not just from the Resources folder. I think I cleared one error by doing that (and replacing the references with the actual .xaml).
You must remove all your .assets files used for XAMLs and Fonts. We no longer use them.
It looks like the Noesis package now actually tries to compile all that when processing assets. This is kind of a problem because some layers down, I am have some code that previously assumed it was happening in game mode that are just null references in the editor. That stuff shouldn't be running yet. Is this a goof on a poor assumption I made previously? Or did the convention on all this actually change?
This is not new, it was happening in previous version of Noesis, we need to load XAMLs (and create components) to generate thumbnails and to give proper parsing errors at edit time. Your UI classes will be created and Initialized (and Loaded for the thumbnail if you have them enabled).
 
Rocko Bonaparte
Topic Author
Posts: 39
Joined: 13 Oct 2020, 08:32

Re: Adjusting to new NoesisGUI release for Unity

27 Sep 2022, 09:23

Is there anything I can do to, say, crank up the verbosity level to try to determine why one Xaml load is triggering another? I purged all the .asset files and it didn't fix one particular problem with a Xaml not being found. It looks like when I enter play mode, UnityEngine.GUIUtility.ProcessEvent is triggering the Noesis run time to load A.xaml.

This xaml has a reference to a theme.xaml which is self-sustaining. However, it somehow decides while loading A.xaml to start trying to load B.xaml. So the InitializeComponent in my A codebehind that just runs a NoesisUnity.LoadComponent(this) windows up loading in B.xaml. I'm trying to figure out what is making that decision. It's opaque from where I sit.

B.xaml does exist and I can explore it in the editor. The path where it can't resolve it is accurate. That codebehind is failing when it tries to call its own NoesisUnity.LoadComponent(this) line.
 
User avatar
jsantos
Site Admin
Posts: 3545
Joined: 20 Jan 2012, 17:18
Contact:

Re: Adjusting to new NoesisGUI release for Unity

27 Sep 2022, 11:52

If you click on a XAML, the inspector panel will give you information about dependencies (Textures, Fonts, Audios, Videos, XAMLs, Shaders). B.xaml should be listed there. If it is not listed, and it is being loaded, that could explain why it is not found on standalone.
 
Rocko Bonaparte
Topic Author
Posts: 39
Joined: 13 Oct 2020, 08:32

Re: Adjusting to new NoesisGUI release for Unity

28 Sep 2022, 08:57

Update: I think I see one common linkage. Both xaml files have a DataContext to a view model in A.xaml's codebehind. I ran out of time tonight fighting with attaching the debugger (attaching to Unity can be like that pretty often) inside the view model's constructor to see if it's trying to get invoked or anything. I don't really know. I'm also not so sure what to do to get around it. Put the view model in a separate file and then . . . stuff?

Original Response:

B.xaml is not listed as a dependency on A.xaml in the inspector. It's not listed as one in the actual file either. It never was, so I don't understand how it winds up thinking it needs it now.

It's not a case of having a field for it in the inspector set to None; it's outright just not there. The only thing I have in the XAMLs section for A.xaml is Theme.xaml, which is what I expect. I have a ResourceDictionary element for Theme.xaml in A.xaml.

If I try to get cute and create a merged resource dictionary also referencing B.xaml, I get all kinds of hideous errors. I think the problem with that particularly is both the A and B XAML files are describing user controls and I get stuff like:

[NOESIS/E] Assets/Project/UI/wpf/mainmenu/B.xaml(18): Can't create an instance of 'ResourceDictionary' inside the same control type.

So I can't establish why the control represented in A.xaml leads is chained to B.xaml and that's why I hoped something could log what thing here or there noticed it needed B.xaml.

I can't say I'm God's gift to Noesis or even WPF right now since it's been, like, a year since I had to edit any of this. So I'm sure there's some goofy thing somewhere, but the whole thing is very opaque from the debug trace and I'm just not seeing it from manual inspection.
 
User avatar
jsantos
Site Admin
Posts: 3545
Joined: 20 Jan 2012, 17:18
Contact:

Re: Adjusting to new NoesisGUI release for Unity

28 Sep 2022, 10:45

Are you able to reproduce your problem in a simpler scene? We need a minimal example because there could be many things involved at the same time in what you are describing.
 
Rocko Bonaparte
Topic Author
Posts: 39
Joined: 13 Oct 2020, 08:32

Re: Adjusting to new NoesisGUI release for Unity

28 Sep 2022, 18:29

I don't know. At this point, the code is kind of legacy and I have to do a lot of relearning to even be able to model what I think the problem could be, let alone what it actually is.

I am guessing the answer to my question about additional logging and diagnostics is "No."
 
User avatar
jsantos
Site Admin
Posts: 3545
Joined: 20 Jan 2012, 17:18
Contact:

Re: Adjusting to new NoesisGUI release for Unity

29 Sep 2022, 10:19

You can increase the verbosity logging in our settings panel. But I think that's not going to help here.

Who is online

Users browsing this forum: Google [Bot] and 1 guest