|
11
|
| ElektroStudios · 技术社区 · 7 年前 |
|
1
2
这的确是一种非常令人讨厌的行为。但是,我不相信您可以绕过它:不是属性描述符出了问题-它报告了正确的类别-您可以通过以下方式进行验证:
所以这只是集合编辑器UI控件的一个怪癖。奇怪的是,如果你再加上一个
属性,它将开始显示两者的类别。但是如果你再加上一个
只读
属性:它不显示类别。这两种情况都适用
所以:我不认为这里有一个好的解决方案,除了使用不同的属性网格实现,或者添加一个虚拟的可写属性——对不起!
作为旁注/无关注意事项:使用
|
|
|
2
2
向类中的虚拟可写但不可浏览属性问好。 当然,这是属性网格bug(?)的一个解决方案,但是考虑到创建自定义集合编辑器表单和实现自定义UITypeEditor所需的开销,而自定义UITypeEditor反过来将使用自定义表单来克服此行为,它至少应该被命名为一个半优雅的解决方案。 代码:
如果仍要为集合实现自定义编辑器,请在中签出接受的答案 this thread . 它并没有贯穿整个过程,但它是一个很好的起点。
|
|
3
2
这不是一个bug,属性网格就是这样设计的。如果组件的所有属性都是只读的,则认为组件是“不可变的”。在本例中,它被包装到那个时髦的“Value”包装器属性中。 一种解决方案是声明一个自定义 TypeDescriptionProvider 在引起问题的类(或实例)上。 custom type descriptor 实例,该实例将添加一个虚拟的不可浏览(对属性网格不可见)非只读属性,因此该类不再被视为“不可变”。 这是您可以使用它的方式,例如:
正如预期的那样,情况将是这样的:
此解决方案的优点是不需要对原始类进行任何更改。但它可能在代码中有其他含义,因此您确实希望在您的上下文中测试它。另外,请注意,一旦网格关闭,您可以/应该删除提供程序。 |
|
|
4
2
这不是你的错
正如其他答案所建议的,您可以通过
但是我不希望仅仅因为
因为问题出在
|