找到一个更好的方式来编写复杂的用户界面WPF

WPF应用程序我继承包含如下类似的模式XAML的显著量：找到一个更好的方式来编写复杂的用户界面WPF

<Window ...> 
    <Grid> 
     <z:SomeUserControl> 
      <z:AnotherUc> 
       <Label /> <Button /> <ComboBox /> 
      </z:AnotherUc> 
      <z:AnotherUc> 
       <Label /> <Button /> <ComboBox /> 
      </z:AnotherUc> 
     </z:SomeUserControl> 
    </Grid> 
</Window>

换句话说，我们的UI部分由用户控件分组，通常嵌套在其他UserControl内。在某些时候，内容是使用基本的WPF内容控件定义的。

我们试图应对的问题是，在X：名称属性不能被应用于任何最内部控制，由于臭名昭著的WPF限制：

Cannot set Name attribute value {0} on element {1}. {1} is under the scope of element {2}, which already had a name registered when it was defined in another scope

这提出了一个问题，因为代码隐藏需要能够引用UserControl中的元素。用户控件被选中以将用户界面的一部分分组，因为所有的默认控件的样式和模板都是因为太笨拙和标记很快变成了一个可怕的，难以理解的混乱。

但是，如果微软无意解决这个所谓的“限制”，那么必须找到更好的方法。考虑到已使用CS +外部XAML模板文件，请参见GaryGJohnson在连接站点上的解决方法。然而，这有一种sphagetti的感觉，任何中断绑定的东西都是不行的。

来源

2011-01-24 Kivin

我遇到了类似的问题，我使用了CustomControl项目。但是现在我知道一切都可以使用MVVM和行为来完成。所以我尽量避免使用x：Name属性。 – vorrtex 2011-01-24 20:14:17

这里最好的选择通常是避免在这些“内部”元素上使用代码。您仍然可以使用数据绑定，因此将它们绑定到DataContext中的属性将可以正常工作。

当然，另一种选择是直接将标签/按钮/组合框公开为AnotherUc类的依赖属性。这将允许您直接将它们用作UserControl的成员，从而避免了范围问题。

当然，这个缺点是您必须为特定的元素组合定制用户控件，而不是允许在其中放置任何控件。

来源

2011-01-24 17:50:19

听起来像一团糟的设计。您可以创建自己的AttachedProperty - MyNameProperty，将其设置在您的XAML中，然后编写您自己的逻辑/视觉树辅助程序，它可以工作。我并不是说我会那样做，但是如果你需要一个快速的解决方法（不需要对你的UI组合模型进行根本性的重新设计），那可能会对你有用。

来源

2011-01-24 20:02:44

如果你可以发布一些松散的xaml，我可以分享我的想法。上面发布的那个看起来像是ItemsControl'ing的好候选者 - 即具有通用UI元素的重复项目可以被当作ItemsControl项目来分解。 – 2011-01-24 20:08:29

找到一个更好的方式来编写复杂的用户界面WPF

回答

相关问题