Hello,
We have a few xaml pages/screens now and expect to grow quickly.
We frequently have to answer questions like:

1. Why did a specific `noesis:SetFocusAction` not actually set focus
   -- usually because element is not visible yet, but sometimes because something else stole focus
   -- currently I put prints into triggers to debug this
2. Why did `noesis:GamepadTrigger ` not trigger
   -- often because element has no focus
   -- this is hard to debug as I'm not sure how to nicely track where input bubbles / tunnels.
3. Why did an event (focus or datatrigger) trigger twice
   -- our best guess: because the first action changed the visual tree and then event continued bubbling/tunneling
   -- we fix this by adding code behind e.handled

These are somewhat different problems and maybe hard to fix with a single tool.
I'm wondering if there's a tool, internal or otherwise that helps you or other teams track / visualize where an event is going / what is executing and maybe even why a trigger (portion of visual tree) hasn't been touched / not getting evaluated / getting skipped.

• Maybe this is more of a process question, how do you track event issues?
• Maybe a feature request for breakpoints in xaml? (or variation on the theme, maybe in the Inspector tool?)
• Maybe a question about where in noesis source should I put breakpoints so I can see evens getting evaluated / xaml lines getting executed.

Hi,

1. We've been thinking on adding a Trace property on Triggers and Actions to automatically log information if triggers are fired or not and the reason, and if actions are succesfully executed or not. For example, the SetFocusAction can log if focus was correctly set, or when failed if the target was disabled or not visible.

2. In our Inspector tool the last button in the hierarchy toolbar when checked "Tracks the focused element". In combination with the "Display layout adorners" it will allow you to easily follow the focused element in your view. You can also log the changes of focus by registering to PreviewGotKeyboardFocus and PreviewLostKeyboardFocus in the root of your view. Knowing which element has the focus is fundamental to know if KeyTrigger/GamepadTrigger will be executed, because they only work if the triggers are placed in an element that is part of the tunneling/bubbling route of the event (generated from the focused element).

3. I don't fully understand this, could you elaborate a bit more?

The Inspector tool should help you analyze the state of the tree and detect many things because you can see the values of all the properties and elements in the tree, and where those values are coming from (local, style, template, animation, binding...).

Routed events are all raised from the UIElement class, so RaiseEvent method wiil be the better place to put breakpoints. And for the xaml triggers/actions I think the idea mentioned above of having a Trace property could be enough. But I don't see an easy way to incorporate any visual aid for events in our Inspector tool, as there are a lot of them happening and they are raised in many elements at the same time.

Cheers.

We also have an internal ticket for bringing features from Snoop into our Inspector tool:

• https://github.com/snoopwpf/snoopwpf
• https://docs.devexpress.com/WPF/403593/ ... ting/snoop

There is an interesting feature for debugging routed events that I think we should implement. We added internal support for console commands in Noesis long time ago. So we could implement a new event tracing command like: And this will emit log information about the bubbling of that event. I think this could be extended to Triggers too and probably wrapping everything in a nice UI.

Amazing, thank you.
Some comments:
1 - Trace on triggers and actions would be amazing, I'd be looking for names of elements trigger touches and/or complete path from MainWindow to the element. Then, if say focus didn't take, properties that made it so (focusable false).
2 - Inspectors "track focused" is excellent and we use it often to debug why something didn't get focused .. or where focus went. Thank you. we will try "PreviewGotKeyboardFocus" and "PreviewLostKeyboardFocus" !
3 - we've had instances a few times when a single datatrigger was was triggered twice on a single action (last time click would trigger twice). I feel like trace from (1) would really help here.
Thank you, I'll take a look at "RaiseEvent" !

I didn't realize snoop exists! This functionality in inspector or even just agility to log it would be wondaful.

Hello,
I'm wondering if you have a request for event trace in Inspector already or should we create a new one? (so we can have an idea for an eta on it)
Cheers.

Yes, please create a new ticket for this. Thank you.

Ok, created here #2433
Thank you!

Thanks again