I created this ticket for the issue:

https://www.noesisengine.com/bugs/view.php?id=3765

Hey, indeed if I simply add it to a merged dictionary in the view, it does actually reload as expected for that view. But if it's just used as a global resource, the file doesn't reload (LoadXaml in the XAML provider doesn't get called even though the XAML provider is notified that the file has chan...

Hello again! It was a while since I made this thread, but I want to revive it since this is very much related. Is it correct that hot reloading of global resources was implemented? The patch notes for 3.2 mentioned that the hot reload algorithm was reimplemented. And the documentation page for Hot R...

Correct, for binding errors, so #2222 indeed. Thanks, that's great to hear!

For example, in your case, bindings are applied after parsing (there is a ticket to improve this #2222). WPF is doing exactly the same in this case, but we could provide a better solution. Hi, just wanted to check, has there been any further work on this? We're getting quite a few error messages in...

Created a bug ticket for this now: https://www.noesisengine.com/bugs/view.php?id=2915

The crash itself is on our end, so no need to worry about that. I analyzed the issue further, testing with a regular TextBlock. What I found was that when adding the inlines in XAML, it seems to work fine and doesn't cause a crash, regardless of whether I use TextBlock or our ParsedTextBlock. But wh...

Hello, we have some code where we rely on the Unloaded event to be executed for the UI element that the user is currently hovering over as we have some custom logic for keeping track of what is being hovered over. However, we have run into an issue where the Unloaded event is not always fired, and I...

Ah yep, that makes sense then! Indeed, having that information for bindings would be amazing. I get that WPF also doesn't solve this, but any improvements you could find for this would be very appreciated. Nice to hear that there's a ticket for it already. :) Haven't tried the VSCode extension yet, ...

Interesting, we're currently on version 3.1.4. Perhaps there's something we haven't set up correctly, given that our Noesis error messages print in the format I pasted above (with no information about XAML file). We have a log handler set via Noesis::SetLogHandler.