|
|
This is something that would also be very helpful to us at Paradox, so we second this request.
We had some additional ideas for this that we have previously discussed in email and on the forum, but I thought I would collect all of it here.
The main idea would be that each element in the UI hierarchy would store metadata about in which XAML file and line it is defined. This might for example be stored in a dependency property or such.
Use cases:
- Show XAML file and line in binding errors. This is what is already requested in this ticket. We would like to also extend this error message improvement to errors in converters. This would make it much easier to fix binding errors and converter errors.
- Building a tool (similar to the Noesis Inspector) that lets you click on a UI element in the game, which immediately opens the relevant XAML file and line in an editor. This removes all the extra work of having to look around to find where a UI element is defined, and instead lets you immediately get to where you need to be. This would make the overall workflow of working with the UI much smoother. We could build this tool ourselves on top of the metadata, but it could make sense for Noesis to natively have such functionality too.
- Finding file and line information in the debugger. When debugging UI code, especially crashes and asserts, it can be difficult to figure out which UI element you're actually looking at in the debugger. It would help a lot if we can see the file and line for a UI element in the debugger. This could possibly be done through Natvis and such, if the metadata exists.
I also want to add that if all the UI elements in the hierarchy has this metadata, then we can visualize what is essentially a call stack, by walking up the hierarchy. This is very useful if a UI element is for example defined inside of a control template, and you need to know the context where the template was instantiated in order to make proper use of the metadata.
Lastly, there are some cases where we create UI elements from code, which means that there's not necessarily a XAML file involved. In these cases we need to be able to manually set the file metadata from code, to something else that is more useful. For example if we're generating UI text inlines from our localization files, we might set this metadata to point to the appropriate place in the localization file. |
