Today I rebuilt a WPF application - .NET Framework 4.8 - and our tester came back to me saying that an error was being raised:
A TwoWay or OneWayToSource binding cannot work on the read-only property
The error itself is not a problem. I immediately recognised it for what it was, went to the problematic Binding, added Mode=OneWay and the problem went away.
But here's the problem
The original binding was already in the code. Just on a different control. It didn't cause a problem there... but if the property it's binding to is ReadOnly, shouldn't it have caused a problem wherever it's used?
The reason this bothers me so much is that our tester also reported that before the error was raised the application seemed "slow". So it occurred to me that using TwoWay bindings where OneWay bindings should be used, even if WPF is somehow catching and handling the error, is causing a performance impact. If that is the case I need to take action.
My questions therefore are:
- Does WPF sometimes handle TwoWay binding errors so that the application continues to work even if the TwoWay binding is inappropriate
- Can using TwoWay binding inappropriately cause a significant performance impact and should I address it?
CodePudding user response：
Does WPF sometimes handle TwoWay binding errors so that the application continues to work even if the TwoWay binding is inappropriate
It did before .NET Framework 4.5.1. Since this update, it throws an InvalidOperationException saying exactly "A TwoWay or OneWayToSource binding cannot work on the read-only property".
Can using TwoWay binding inappropriately cause a significant performance impact and should I address it?
No. But you should obviously avoid TwoWay bind to read-only properties to avoid getting the exception.