Hi,
This behavior is not the same as Microsoft's TreeViewItem.
If I host let's say multiple RadTreeView in a Docking system, each in a different RadPanel where each TreeView is contained in a UserControl with FocusManager.IsFocusScope = true (this is important for proper RoutedCommand routing), then as I select a node in each treeview and activate different panels, the highlighted "focused" state stays on, they don't turn to gray. I find this very confusing in the UI because now you don't know which treeview has actual focus (other than seeing which panel is active.) Press an arrow key, hmm, I wonder which treeview's will act upon it. :) We also have a mixture of WPF controls and your Rad controls, so they are dealing with lost focus with selection in inconsistent ways.
(This actually occurs for all your controls, like RadGridView and RadPropertyGrid, but I'm picking on the radtreeview for now.)
The main question is: Was this intended behavior? If yes, then I guess I'll move on, sadly (maybe change your source code). I might then ask why you wanted to deviate from Microsoft's default behavior, since generally I'm seeing an effort in most of your controls to try to emulate the WPF controls pretty closely (at least the simple ones :)). Or why you didn't want to provide a property to choose between this behavior or the default (Microsoft) way.
For tech talk, if you use ILSpy and look at WPF's TreeViewItem.ChangeVisualState(), you'll see that Microsoft is looking at IsKeyboardFocused to determine whether to highlight or gray out a treeviewitem. In your RadTreeViewItem.ChangeVisualState(), you are checking IsFocused, which is logical focus, not keyboard focus. That's why all my treeviews show a highlighted blue selected node at the same time.
1 Answer, 1 is accepted
Thank you for sharing your case here.
Indeed, the Telerik controls are trying to get close to the look-and-feel of the native WPF and even extend them. But this is not a rule and you can't expect that a control from the UI for WPF suite will behave exactly as its native alternative. Currently, most of the items control components rely on their logical focus to update the selection unfocused visual state. I can agree that in some cases it is more reliable to use the keyboard focus. If you think that this is a good-to-have feature (behavior) you can post it in the UI for WPF feedback portal.
To answer your main question, no, I wouldn't call it intended behavior, but also it is not unintended. It's more like a scenario which is not taken into account when the controls have been designed.
You can work this around by implementing some custom visual state changing logic.
Regards,
Martin
Telerik by Progress