I have managed to reproduce the issue with variable success. It seems to be a bug in the highlighting when there has been an invalid expression followed by a change in the invalid expression text or another invalid expression. There is no way at the moment to force the highlighting logic to be executed externally. Furthermore, I cannot seem to find a decent workaround in order to set a light foreground color in every case, especially when the value is coming from an external source - like a binding. I have logged a bug report about this issue and you can track its progress here.
I have updated your points for reporting that.
One very questionable suggestion could be when the external expression value is changed, first to pass to the RadExpressionEditor
a valid expression (might be even - (just a minus sign)) and after that to pass the new value.
As for the ScrollViewers
- the border for the info (x:Name EditorInfoPanel
) has a MinHeight
of 76 and when there is not enough space it stands on top of the 2 trees. They have a MinHeight
of 146. For this theme with the current template, the RadExpressionEditor
needs at least 420 available height for the ScrollViewers
to fit entirely. You can modify the template of the RadExpressionEditor
to change these values to better fit your project.
Telerik by Progress
Want to extend the target reach of your WPF applications, leveraging iOS, Android, and UWP? Try UI for Xamarin
, a suite of polished and feature-rich components for the Xamarin framework, which allow
you to write beautiful native mobile apps using a single shared C# codebase.