仅当树项的父项是列表中的第一个时，WPF 将命令标记为不可用的方法是什么? [英] What’s the WPF way to mark a command as unavailable only if the parent of a tree item is the first in the list?
问题描述
我有一个代表某些项目的树视图.这棵树总是两层深.子项的右键单击菜单有一个向上移动"命令.用户界面允许您向上移动子项，即使它是其父项的第一项，只要在父级有另一个项位于所选项的父项之上.
I have a tree view representing certain items. This tree is always two levels deep. The right-click menu for the child items has a "move up" command. The UI allows you to move a child item up even if it’s the first item of its parent, as long as there is another item at the parent level, above the selected item’s parent.
显而易见的方法是获取所选项目的父项，并查看其上方是否有项目.但是，在 WPF 中获取所选项目的父级绝非易事.同样，显而易见(无论如何对于 WPF 初学者)方法是获取所选项目的 TreeViewItem，它具有 Parent 属性.不幸的是，这也很难做到.
The obvious way to do this is to get the selected item’s parent and see if there are items above it. However, getting the selected item’s parent in WPF is anything but trivial. Again, the obvious (for a WPF beginner, anyway) approach is to get the TreeViewItem for the selected item, which has a Parent property. Unfortunately, this is also hard to do.
从有人说这很难，因为我正在做错误，我决定询问那些对 WPF 更有经验的人:什么是正确的、非难的方法来做到这一点?从逻辑上讲，这是微不足道的，但我无法找出处理 WPF API 的正确方法.
Taking the hint from someone who says it’s hard because I’m doing it wrong, I decided to ask those more experienced with WPF: what’s the right, non-hard way to do this? Logically it’s trivial, but I can’t figure out the correct way to deal with the WPF APIs.
推荐答案
您说得对，用 Wpf TreeView 做这种事情很痛苦.原因的一个关键部分是 Wpf 为您提供的灵活性 - 例如，您可以覆盖自定义 TreeView 中的 ItemContainerGenerator 并且您的树视图可能实际上不包含 TreeViewItem 对象.即没有您在可比较的 Winforms 控件中找到的相同的固定层次结构.
You are absolutely right that doing this kind of thing with the Wpf TreeView is painful. A key part of the reason for that is the flexibility that Wpf gives you - you could have overriden the ItemContainerGenerator in a custom TreeView and your tree view might not actually contain TreeViewItem objects, for example. i.e. there isn't that same fixed hierarchy that you find in a comparable Winforms control.
一开始这看起来确实有悖于直觉，而且 MS 没有花更多时间解释如何以不会导致沮丧的方式使这种事情发挥作用，真是令人遗憾.
It really seems counter intuitive at first and it's a real shame that MS didn't spend more time explaining how to make this kind of thing work in a way that doesn't lead to frustration.
自从采用 MVVM 以来，我们在 Wpf 方面取得了巨大的成功 - 到我们总是为绑定到 UI 的类创建一个 ViewModel 的地步，无一例外 - 在新的功能稍后上线.
We've had huge success with Wpf since embracing MVVM - to the point where we always create a ViewModel for classes bound to the UI, without exception - it's just that much easier to wire in new functionality later down the line.
如果你有一个你的树视图绑定到的底层视图模型(或者甚至模型项，如果你必须的话)，并且把树视图看作只是一个观察者，你会更好地与 Wpf TreeView 和其他 Wpf 控件相处也.实际上，对于树绑定层次结构，您将拥有 TreeView 正在可视化的视图模型对象的层次结构 - 每个子级都有一个返回其父级的句柄，每个父级都有一个子视图模型的集合.然后，您将拥有每个项目的分层数据模板，其中 ItemsSource 是 ChildCollection.然后，您针对 ViewModel 发出MoveUp"命令，它负责进行更改 - 如果您使用基于 ObservableCollection(或实现 INotifyCollectionChanged)的集合，则 TreeView 会自动更新以反映新的层次结构.
If you have an underlying viewmodel (or even model item if you must) that your tree view is bound to, and think of the treeview as just an observer, you will get along much better with the Wpf TreeView and other Wpf controls too. In practical terms for a tree bound hierarchy, you would have a hierarchy of viewmodel objects that your TreeView is visualizing - where each child has a handle back to it's parent, and each parent has a collection of child viewmodels. You would then have Hierarchical data template for each item, where the ItemsSource is the ChildCollection. You then fire off your "MoveUp" command against the ViewModel, and it takes care of making the change - if you are using collections based on ObservableCollection (or that implement INotifyCollectionChanged) then the TreeView updates automagically to reflect the new hierarchy.
从 ViewModel 驱动功能，并将 UI 视为反映 ViewModel 层次结构和属性的薄层，这使得代码可以进行高度的单元测试 - 代码隐藏中没有代码，您通常可以在没有任何 UI 的情况下测试您的 ViewModel 功能，从长远来看，这有助于提高代码质量.
Driving the functionality from the ViewModel, and seeing the UI as just a thin layer reflecting the ViewModel hierarchy and properties makes for code that can be unit tested to a high degree - with no code in the code-behind, you can often test your ViewModel functionality without any UI at all which makes for much better quality code in the long run.
当我们开始使用 Wpf 时，我们的自然反应是 ViewModels 是矫枉过正，但我们的经验(在许多地方开始时没有使用它们)是它们在 Wpf 中开始很快见效，毫无疑问，值得付出额外的努力让你的头脑周围.
The natural response for us when we started with Wpf was that ViewModels were overkill, but our experience (having started off without them in many places) is that they start paying off pretty rapidly in Wpf and are without doubt worth the extra effort to get your head around.
您可能还没有遇到的一件事，我们发现这真的很痛苦，就是在树视图上设置所选项目 - 现在这不适合胆小的人:)
One thing you might not have hit yet, which we found really painful, was setting the selected item on a treeview - now that's not something for the faint of heart :)
这篇关于仅当树项的父项是列表中的第一个时，WPF 将命令标记为不可用的方法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
