Debugging advice
Any debugging tips from Noesis pros?
Since the engine is pretty opaque, I was trying to think of ways to add more logging. I was thinking of adding a new action, "Log Action", but it isn't clear from reading the docs that I'm even able to do this. Has anyone else tried this?
I see that many of the other actions are actually implemented in Noesis in C#, so I was also just considering adding logging to all of them. This would also be helpful, but pretty spammy vs. just a single "log" action, so I'd have to filter through everything to find the logs I actually cared about.
Any other suggestions for debugging? Especially storyboards?
thanks,
sam
Since the engine is pretty opaque, I was trying to think of ways to add more logging. I was thinking of adding a new action, "Log Action", but it isn't clear from reading the docs that I'm even able to do this. Has anyone else tried this?
I see that many of the other actions are actually implemented in Noesis in C#, so I was also just considering adding logging to all of them. This would also be helpful, but pretty spammy vs. just a single "log" action, so I'd have to filter through everything to find the logs I actually cared about.
Any other suggestions for debugging? Especially storyboards?
thanks,
sam
-
-
sfernandez
Site Admin
- Posts: 2999
- Joined:
Re: Debugging advice
Hi Sam,
All the interactivity triggers and actions are implemented in C# with source code available, so you can modify anything you need. But as you said it would be better if you just write your own action by inheriting from TriggerAction or TargetedTriggerAction.
The Inspector is very useful for debugging as you can check the values of all the properties of any element in the UI tree and see where the value comes from: animation, bindings, styles...
Sometimes I find convenient to add some debug TextBlocks with bindings that can serve as on screen logging.
Will be great to hear what other users are doing, and how can we improve on this aspect.
All the interactivity triggers and actions are implemented in C# with source code available, so you can modify anything you need. But as you said it would be better if you just write your own action by inheriting from TriggerAction or TargetedTriggerAction.
The Inspector is very useful for debugging as you can check the values of all the properties of any element in the UI tree and see where the value comes from: animation, bindings, styles...
Sometimes I find convenient to add some debug TextBlocks with bindings that can serve as on screen logging.
Will be great to hear what other users are doing, and how can we improve on this aspect.
-
-
sfernandez
Site Admin
- Posts: 2999
- Joined:
Re: Debugging advice
Just as an example of a possible LogAction for Unity:
Code: Select all
public class LogAction : NoesisApp.TriggerAction<UIElement>
{
public string Message
{
get { return (string)GetValue(MessageProperty); }
set { SetValue(MessageProperty, value); }
}
public static readonly DependencyProperty MessageProperty = DependencyProperty.Register(
"Message", typeof(string), typeof(LogAction), new PropertyMetadata(string.Empty));
protected override void Invoke(object parameter)
{
UnityEngine.Debug.Log(Message);
}
}Code: Select all
<ei:DataTrigger Binding="{Binding Active}" Value="True">
<local:LogAction Message="This message will be logged to Unity console"/>
</ei:DataTrigger>-
- ai_enabled
- Posts: 231
- Joined:
- Contact:
Re: Debugging advice
Hello!
If you want to have more details from NoesisGUI you can subscribe to its logging API (e.g. in C# SDK you can use Noesis.Log.SetLogCallback method). It produces plenty of information such as XAML loading events, binding errors, etc. If you have a full source code license for NoesisGUI you can expand its C++ code to add more logging and it will propagate via the logging callback to your application.
But what is the purpose of the extra logging in your case? To help investigate the issues in bug reports? For testing during development?
I have over a decade of experience with WPF and using NoesisGUI successfully since 2013. In my case, there was never a need to produce a verbose log about every action performed by WPF/NoesisGUI. Our logs for bug reports contain plenty of hand-written application-level logging to help us locate the issue. We can understand perfectly what was going on before the issue happened—unlike some generic logging about UI clicks/actions which would not be helpful (at least not helpful without manual application-level logs). I would also recommend using MVVM approach whenever possible as it produces the most simple code that is fairly easy to write/read/debug—unlike spaghetti code that often appears when trying to write code in codebehind.
For development, I'm usually attaching with a debugger instead of enabling low-severity logging or writing extra logging code on the application level. Though with MVVM approach I rarely need a debugger! The application is composed of plenty of small single-purpose user controls and view models, so if one component fails it's obvious what doesn't work as intended.
Regards!
If you want to have more details from NoesisGUI you can subscribe to its logging API (e.g. in C# SDK you can use Noesis.Log.SetLogCallback method). It produces plenty of information such as XAML loading events, binding errors, etc. If you have a full source code license for NoesisGUI you can expand its C++ code to add more logging and it will propagate via the logging callback to your application.
But what is the purpose of the extra logging in your case? To help investigate the issues in bug reports? For testing during development?
I have over a decade of experience with WPF and using NoesisGUI successfully since 2013. In my case, there was never a need to produce a verbose log about every action performed by WPF/NoesisGUI. Our logs for bug reports contain plenty of hand-written application-level logging to help us locate the issue. We can understand perfectly what was going on before the issue happened—unlike some generic logging about UI clicks/actions which would not be helpful (at least not helpful without manual application-level logs). I would also recommend using MVVM approach whenever possible as it produces the most simple code that is fairly easy to write/read/debug—unlike spaghetti code that often appears when trying to write code in codebehind.
For development, I'm usually attaching with a debugger instead of enabling low-severity logging or writing extra logging code on the application level. Though with MVVM approach I rarely need a debugger! The application is composed of plenty of small single-purpose user controls and view models, so if one component fails it's obvious what doesn't work as intended.
Regards!
AtomicTorch Studio Pte. Ltd. http://atomictorch.com