-
Notifications
You must be signed in to change notification settings - Fork 7
Description
Been using this package for a couple years now. This has been plaguing me for the last few weeks and unfortunately it is mist. Set a breakpoint at either sb.Append below. When you get there, a hover over sb will say it is null - it is not. Duplicated variable names in different scopes is what is causing this issue - different names work. Comment out the one property - and it works. We have 10 years of code (not by me and not close to mvvm) which is being re-purposed and I have been porting mist into the new derivatives. The debugger is near useless to try to understand old code when you can't trust it.
Note: don't know why this isn't formatting correctly.
` [Notifier(NotificationMode.Implicit)]
public partial class MainWindow : Window, INotifyPropertyChanged
{
public MainWindow()
{
InitializeComponent();
int x = 3;
if (x > 12)
{
var sb = new StringBuilder();
sb.Append($"{x}");
sb.ToString();
}
else
{
var sb = new StringBuilder();
sb.Append($"{x}");
sb.ToString();
}
}
// comment out this property and debugger works
public bool Checked { get; set; }
public event PropertyChangedEventHandler PropertyChanged;
[NotifyTarget]
protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null) => PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
}
`
This is absolutely killing me. I am the only person at this company who is not afraid of extensions or nuget. Every time I have an issue they say "well what extension do you have that is causing it because it doesn't happen to me". If I tell them I have to rip this out - they will simply stop me from using anything but vanilla everything.
I love this thing and am using it against the caution from my boss and a couple of my coworkers hate it. (Good guys, mechanical engineers who write code, but very conservative when it comes to SW)