关于泛型控件和窗体继承。。。

[lovingkiss]

泛型控件的继承，继承后无法进行可视化编辑
网络上给出的解决方案，是增加一层中间继承的类。
但是这样会导致，有多少个继承就要增多多少个无谓的中间层。

有没有更好的解决办法，或者说能写个通用的中间层。

[大鱼>]

泛型控件是什么？怎么样的一种概念？或者说的泛型控件只是泛型集合？

[正怒月神]

泛型控件是什么？
这个泛型对控件有哪些影响？

[lovingkiss]

引用 6 楼 xuzuning 的回复:

泛型控件 是什么？

引用 7 楼 qq_17486399 的回复:

泛型控件是什么？怎么样的一种概念？或者说的泛型控件只是泛型集合？

引用 8 楼 hanjun0612 的回复:

泛型控件是什么？
这个泛型对控件有哪些影响？

就是普通控件，加上泛型的约束。
例如 public class ExtGridView<T>:Usercontrol....

在使用时，可以直接传递类型进入，返回值比较方便 可以直接返回T DataItem

内部处理也可以根据T的约束直接写通用方法。

[以专业开发人员为伍]

比如说 X<T>，这里什么是类型？难道你以为 X 是一个单独的类型？

你要实际去“编辑”，自然地，你就需要写 X<int>、X<string>、X<MyType> 之类的实际的类型。这时候你就必须给每一个真正的类型指定一次名称。而 vs 不过就是让你写个

class ABC: X<int>
{
    .....
}

这类而已，这不叫做“无谓的中间层”，因为你起的名字 ABC 是用来索引这种实际的代码生成内容的程序地址的。而 X<int> 并不能（至少现在还没有）表示由 vs 生成的代码，它只能表示运行时由 JIT 编译器处理的代码。

[以专业开发人员为伍]

你如果调用编辑器组件，完全可以自己把编辑结果保存下来，然后将来实例化对象实例时再去为对象赋值。这是你自己的设计。

但是假设你使用 vs，并且将结果保存为 cs 文件和 designer.cs 文件等，那么就按照它的设计，没有什么“泛型cs文件、泛型designer.cs文件”这种文件。你总归是要给每一个这种文件命名的，是真实地个性化的文件命名，并不是什么“无谓的”命名。

[以专业开发人员为伍]

我们开发一个一个自定义组件，总归是要产生 cs、designer.cs 文件等等工程文件。

别被“泛型”这个字眼儿给弄得头脑发昏，好像有了泛型概念就不用开发和保存组件的文件了似地。

[lovingkiss]

引用 1 楼 sp1234 的回复:

比如说 X<T>，这里什么是类型？难道你以为 X 是一个单独的类型？

你要实际去“编辑”，自然地，你就需要写 X<int>、X<string>、X<MyType> 之类的实际的类型。这时候你就必须给每一个真正的类型指定一次名称。而 vs 不过就是让你写个

class ABC: X<int>
{
    .....
}

这类而已，这不叫做“无谓的中间层”，因为你起的名字 ABC 是用来索引这种实际的代码生成内容的程序地址的。而 X<int> 并不能（至少现在还没有）表示由 vs 生成的代码，它只能表示运行时由 JIT 编译器处理的代码。

我不太赞同你的观点
class ABC: X<int>
{
.....
}

class ABCD: ABC
{
.....
}
对于设计器来说，能够认定ABCD已经可以可视化编辑了，
对于ABC来说，完全“有能力”可以认定已经对泛型实例化了——只是编译器没有做“识别”而已。
你也说了，这属于（至少现在还没有）。只是没有，不代表将来做不到对吧。

[lovingkiss]

引用 3 楼 sp1234 的回复:

我们开发一个一个自定义组件，总归是要产生 cs、designer.cs 文件等等工程文件。

别被“泛型”这个字眼儿给弄得头脑发昏，好像有了泛型概念就不用开发和保存组件的文件了似地。

这是两个概念好吧，一个自定义的泛型组件，还要再搭配一个中间层组件才能正常使用。
而且也只是因为编译器的不识别，并不是逻辑上不可行。
如果将来vs20XX版实现了这个功能，你今天说的话岂不是打脸？

[xuzuning]

泛型控件 是什么？