Hi everyone, I’m new to NoesisGUI and still getting comfortable with how things are typically organized. I’m working on a small game (menu screens, settings, HUD, etc.) and I’m unsure about the best way to structure everything.

Right now I have separate XAML files for each screen, but it’s starting to feel a bit messy as I add more features. I’m not sure how people usually handle things like navigation between screens, shared styles, or reusable components.

Would you recommend:

• Keeping everything modular (one XAML per screen/component)?

• Using a central UI manager of some kind?

• Relying more on data binding vs. code-behind for interactions?

Also, if there are any common mistakes beginners make when structuring their UI, I’d love to avoid those early.

Thanks in advance!

Hey XdtrojanRua, Dorian from Noesis here! Nice to meet you, and welcome!

Workflow and Screen Management

So in terms of screen management, our recommendation is to essentially have a Main Page that gets loaded in, and which then serves individual screens in the form of ContentControl Content Templates.

What this means in practice, is that your Page will essentially perform the role of a 'UI Manager' as you referred to it,
On this Page, you will have one (or many) ContentControl Elements, and you can then 'switch screen' by simply changing the Template used by the ContentControl's 'Content Template' Property.

This 'changing of screens' is something you can easily drive at runtime by using 📘 Triggers in which you can set one of your Actions to use a ChangePropertyAction Action, which changes the value of the ContentControl's 'Content Template' Property from one 'screen' Template Resource to another. How you fire off this Trigger can either be done via any of the included Events, or can be Data-Driven, whichever you prefer.

The big consideration here in terms of Project structure however, is that Templates such as these are stored as Resources, and not as XAML Pages.
Due to this nature, they are therefore stored in ResourceDictionaries. However, you will need to mindful to ensure that any custom ResourceDictionaries created to store these 'screens' are merged into an accessible scope, so that they too can be accessible (see 📘Merging ResourceDictionaries).

For a small project, its likely the easiest solution to just merge everything into GlobalResources.xaml, then everything you create, is accessible from everywhere within your Project.

You are more than welcome to make one ResourceDictionary per 'screen', however, one benefit of them being Resource-based instead, is that you can actually bundle multiple Screens inside of a single ResourceDictionary if desired.

So for example, you could have a "Settings_Screen_Dictionary" ResourceDictionary, which includes ContentControl Content Templates for "Audio", "Graphics", "Controls", etc...

In terms of workflow, what this represents, is that since 'screens' are created (and edited) as Templates, these can either be opened in context (including their Data Context) directly from the Stage where they are employed, or, alternately, they can be created or edited from the 📘Resources Panel.

Re-Usable Components

As to your question about how to best approach re-usable components; the exact same principles as above at the screen-level, using ContentControl Content Templates (you can really think of your 'components' as 'mini screens' through this lens.)

The same would also apply to for example, iconography.
In fact, you can actually see exactly this system in action in our MiniShowcases Sample Project bundled with Studio, under the 'IconLibrary.xaml' file found within (Row 2 shows examples of this, and you can have fun by selecting any of the icons, heading to its Properties Panel, and under 'Templating', changing the 'Content Template' to swap icons in-place.)

One of the best things about ContentControls is that beyond the ability to swap Templates on-the-fly as explained above, one of their biggest draws is that since they are Data Templates, they are also able to be populated via a DataContext; this makes them a great choice in terms of re-use within a Collection Element (like a ListBox that shows the same Template repeated over and over again, but with different text within each).

You can also check this out in action in the same IconLibrary.xaml file within the MiniShowcases Project (Row 3) which shows a Data-Driven Collection of Iconography.

For a quick lesson on how to approach building Data-Driven Collections, our 🎓 Creating a Character Selection Screen in Noesis Studio showcases these mechanics in-action. (The 'ListBox Item' used in this Tutorial, is another form of a DataTemplate, very similar, and in fact, largely interchangeable with the 'ContentControl' mentioned above).

Data Binding vs Code Behind

To drive interactions, our recommendation is going to be to use Noesis' native suite of Interactivity features (📘 Working With Interactivity), used in tandem with Bindings (either Binding to other Element Properties, or to Data).

The biggest advantages of going this:
- High portability: if you use the built-in feature set, it will work wherever the product is run, whether in Studio Standalone, across different Engines, and across different platforms too.
- Allows you to build everything in a WYSIWYG manner directly within Noesis Studio.
- As long as your ViewModel matches between Studio and your Engine, all of your bindings are completely portable between both contexts; and it therefore benefits from the full power of MVVM.

To learn more about how to approach Data: 📘 Working With Data.

Let's start with all this as a first general round of guidance, with an open invitation to of course, drop back if you have any additional questions or if anything else comes up -- we're here to help!

- Dorian

Hi dstewart,

Is this workflow only for Noesis 4.0? In 3.x I've been using UserControl for every screen as Noesis Studio would not edit templates.

Hi Maverikou,

Both ContentControls and UserControls should be working across every version of Studio.

Let's see if we can diagnose what's going on:

1. Testing that you're able to open ContentControl Templates for edit:

a) If you could please open the included MiniShowcases Sample Project in Studio, then open up the IconLibrary.xaml file within.

b) On this Page, if you right-click any of the icons in the second row, and navigate to 'Templates'-->'Content'-->'Edit', does this open successfully for you in the inline Template Dummy Editor, where you can find all of the Paths that make up the icon artwork?


2. If the previous works, and we've validated that a known example functions as expected, let's move onto some follow-ups:

a) By any chance, if you select the Templates you created via the Resources Panel (Ctrl+5), do they have a 'Data Type' associated with them in their Properties Panel on the right of the screen? If a Data Type is set here that doesn't correspond to the Data Type that is used at the Page level is used, it won't be selectable (or editable) from the Content Control Element's 'Template' selector.

b) Hovering over the 'Data Type', clicking on its 3-Dot Menu, and selecting 'Clear Local Value' to wipe it having a specific Data Type associated with it, and making it 'universal' with no specified value here will generally resolve this issue.
(Related: #4728)


3. If that still is not providing the desired/expected results, let's see if we can narrow down your case:

a) How does the inability to edit ContentControl Templates manifest for you within the context of Studio?

b) Are you able to either share a sample Project or Repro Steps for us to replicate the situation you found?

Let's start here --- thanks for helping us find out what's going on --- we'll get this sorted!

- Dorian

Thank you dstewart!
I was completely missing the 'Templates'-->'Content'-->'Edit' part.
A re-watch of tutorial videos is in order.

I will check my setup regarding your point #2 and will reply in a bit.

Just wanted to confirm that the workflow explained by dstewart works as expected.

Fantastic! Thank you for reporting back to us! Let us know if you come across anything else we can help with!

- Dorian