[Feature Request] Make TextEditor.Text a DependencyProperty so you can bind a Property to it

If you try to add a Binding to TextEditor.Text, the program fails with

Exception thrown: 'System.Windows.Markup.XamlParseException' in PresentationFramework.dll

Additional information: A 'Binding' cannot be set on the 'Text' property of type 'TextEditor'. A 'Binding' can only be set on a DependencyProperty of a DependencyObject.

If you would be OK with post-processing, the easiest way would probably be to add the NuGet AutoDependencyProperty.Fody(https://www.nuget.org/packages/AutoDependencyProperty.Fody/) and decorate the property with [AutoDependencyProperty]. This avoids the ‘code noise’ of Dependency Properties.

[dgrunwald]

Making the Text property a DependencyProperty would cause performance problems when editing large files: the only way to notify WPF that the DependencyProperty value has changed involves calling SetValue() with the new value, which means the whole document text must be provided as an immutable string. When editing a 100 MB document, every key press would have to reallocate the whole 100 MB! Worse: those allocations go to the large object heap, so they can be only freed by a full gen2 GC.

What AvalonEdit currently does is to use a mutable text buffer. The full System.String only gets allocated in the Text property getter, so the string allocation only occurs when necessary, and not on every key press.

By the way, the WPF TextBox internally solves the same problem by using the WPF-internal type System.Windows.DeferredReference, which allows setting a DependencyProperty to a value that is only produced on-demand. Unfortunately this solution is not available in the public WPF API 😦

[mysteryx93]

There are various solutions posted here but I don’t like any of these solutions. The proposed solutions do indeed cause the string to be reconstructed on every key strike to update the dependency property, leading to performance issues.

Binding to Document isn’t working properly, but even if it was, it means writing the MVVM ViewModel around a UI element which defeats the point of MVVM to be UI agnostic.

Honestly, I think the best option is to raise 2 events from the ViewModel, one to display text when it’s really needed, and one to get text when it’s really needed. Perhaps it doesn’t even need to be stored in the ViewModel at all.

Then, would it have been possible to derive TextEditor from the TextBox control to inherit its base features?