我遇到了Windows窗体中的继承控件的问题，并需要一些建议。
我确实对列表（由面板制成的自制GUI列表）中的项目使用基类，并为每种可以添加到列表的数据类型使用了一些继承的控件。
没问题，但是我现在发现，使基本控件成为抽象类是正确的，因为它具有方法，需要在所有继承的控件中实现这些方法，这些控件是从内部代码中调用的。 base-control，但不能也不能在基类中实现。
当我将基本控件标记为抽象时，Visual Studio 2008设计器拒绝加载窗口。
有没有办法使Designer与抽象的基本控件一起工作？
Answers:
我知道必须有一种方法可以做到这一点（而且我找到了一种干净利落的方法）。Sheng的解决方案正是我想出的一种临时解决方法，但是在一位朋友指出Form该类最终从一个abstract类继承之后，我们应该能够完成此工作。如果他们能做到，我们就可以做到。
我们从这段代码转到了问题
Form1 : Formpublic class Form1 : BaseForm
...
public abstract class BaseForm : Form这是最初的问题起作用的地方。如前所述，一位朋友指出System.Windows.Forms.Form实现了抽象的基类。我们能够找到...
继承层次结构：
public **abstract** class MarshalByRefObject）
由此，我们知道设计师可以显示一个实现基本抽象类的类，而不能显示立即实现基本抽象类的设计器类。中间最多只能有5个，但是我们测试了1个抽象层，最初提出了这个解决方案。
public class Form1 : MiddleClass
...
public class MiddleClass : BaseForm
...
public abstract class BaseForm : Form
... 这实际上可以正常工作，并且设计器可以很好地解决问题。...除了您的生产应用程序中具有额外的继承级别，这仅是由于winforms设计器的不足才有必要！
这不是100％surefire解决方案，但它相当不错。基本上，您通常会使用#if DEBUG经过改进的解决方案。
Form1.cs
#if DEBUG
public class Form1 : MiddleClass
#else
public class Form1 : BaseForm
#endif
...MiddleClass.cs
public class MiddleClass : BaseForm
... BaseForm.cs
public abstract class BaseForm : Form
... 如果它处于调试模式，则仅使用“初始解决方案”中概述的解决方案。这样的想法是，您将永远不会通过调试版本释放生产模式，而将始终以调试模式进行设计。
设计器将始终以当前模式下构建的代码运行，因此您不能在发布模式下使用设计器。但是，只要您在调试模式下进行设计并释放在发布模式下构建的代码，您就可以开始使用。
唯一的安全解决方案是您是否可以通过预处理程序指令测试设计模式。
@smelch，有一个更好的解决方案，即使创建调试也无需创建中间控件。
我们想要什么
首先，让我们定义最终类和基础抽象类。
public class MyControl : AbstractControl
...
public abstract class AbstractControl : UserControl // Also works for Form
...现在我们只需要一个Description提供程序。
public class AbstractControlDescriptionProvider<TAbstract, TBase> : TypeDescriptionProvider
{
public AbstractControlDescriptionProvider()
: base(TypeDescriptor.GetProvider(typeof(TAbstract)))
{
}
public override Type GetReflectionType(Type objectType, object instance)
{
if (objectType == typeof(TAbstract))
return typeof(TBase);
return base.GetReflectionType(objectType, instance);
}
public override object CreateInstance(IServiceProvider provider, Type objectType, Type[] argTypes, object[] args)
{
if (objectType == typeof(TAbstract))
objectType = typeof(TBase);
return base.CreateInstance(provider, objectType, argTypes, args);
}
}最后，我们仅将TypeDescriptionProvider属性应用于Abastract控件。
[TypeDescriptionProvider(typeof(AbstractControlDescriptionProvider<AbstractControl, UserControl>))]
public abstract class AbstractControl : UserControl
...就是这样。无需中间控件。
并且，在同一解决方案中，provider类可以应用于所需的任意多个Abstract基。
*编辑* 另外app.config中需要以下内容
<appSettings>
<add key="EnableOptimizedDesignerReloading" value="false" />
</appSettings>感谢@ user3057544的建议。
TypeDescriptionProvider
我有一个类似的问题，但是找到了一种方法来重构事物以使用接口代替抽象基类：
interface Base {....}
public class MyUserControl<T> : UserControl, Base
where T : /constraint/
{ ... }这可能并不适用于所有情况，但在可能的情况下，与条件编译相比，它可以提供更干净的解决方案。
UserControl在界面中添加了一个属性，并在需要直接访问它时引用了该属性。在我的界面实现中，我扩展了UserControl并将UserControl属性设置为this
对于有人说TypeDescriptionProviderJuan Carlos Diaz 的by不起作用并且也不喜欢条件编译的人，我有一些建议：
首先，您可能必须重新启动Visual Studio才能使代码中的更改在表单设计器中起作用（我必须这样做，简单的重新构建不起作用-或并非每次都起作用）。
我将针对抽象基本Form的情况提出我的解决方案。假设您有一个BaseForm类，并且希望基于它的任何形式都是可设计的（这将是Form1）。在TypeDescriptionProvider胡安·卡洛斯·迪亚斯所呈现并没有为我工作也。通过将它与MiddleClass解决方案（通过熔焊）结合起来，但没有#if DEBUG条件编译和一些更正，这就是我如何使其工作的：
[TypeDescriptionProvider(typeof(AbstractControlDescriptionProvider<BaseForm, BaseFormMiddle2>))] // BaseFormMiddle2 explained below
public abstract class BaseForm : Form
{
public BaseForm()
{
InitializeComponent();
}
public abstract void SomeAbstractMethod();
}
public class Form1 : BaseForm // Form1 is the form to be designed. As you see it's clean and you do NOTHING special here (only the the normal abstract method(s) implementation!). The developer of such form(s) doesn't have to know anything about the abstract base form problem. He just writes his form as usual.
{
public Form1()
{
InitializeComponent();
}
public override void SomeAbstractMethod()
{
// implementation of BaseForm's abstract method
}
}请注意BaseForm类上的属性。然后，您只需要声明TypeDescriptionProvider和两个中间类，但是不用担心，它们对于Form1的开发人员是不可见的且无关紧要的。第一个实现抽象成员（并使基类成为非抽象的）。第二个是空的-VS表单设计器只需要工作即可。然后你分配第二中产阶级到TypeDescriptionProvider的BaseForm。没有条件编译。
我还有两个问题：
第一个问题（您可能没有，因为它在我的项目中的其他地方困扰着我，通常会产生“无法将X型转换为X型”异常）。我TypeDescriptionProvider通过比较类型名称（FullName）而不是比较类型来解决它（请参见下文）。
第二个问题。我真的不知道为什么不能在Form1类中设计基本窗体的控件，并且在调整大小后丢失其位置，但是我已经解决了这个问题（不是一个很好的解决方案-如果您知道更好，请写信）。我只是在从BaseForm的Load事件异步调用的方法中，手动将BaseForm的按钮（应该在右下角）移动到它们的正确位置：BeginInvoke(new Action(CorrectLayout));我的基类只有“ OK”和“ Cancel”按钮，因此情况很简单。
class BaseFormMiddle1 : BaseForm
{
protected BaseFormMiddle1()
{
}
public override void SomeAbstractMethod()
{
throw new NotImplementedException(); // this method will never be called in design mode anyway
}
}
class BaseFormMiddle2 : BaseFormMiddle1 // empty class, just to make the VS designer working
{
}在这里，您有的稍微修改版本TypeDescriptionProvider：
public class AbstractControlDescriptionProvider<TAbstract, TBase> : TypeDescriptionProvider
{
public AbstractControlDescriptionProvider()
: base(TypeDescriptor.GetProvider(typeof(TAbstract)))
{
}
public override Type GetReflectionType(Type objectType, object instance)
{
if (objectType.FullName == typeof(TAbstract).FullName) // corrected condition here (original condition was incorrectly giving false in my case sometimes)
return typeof(TBase);
return base.GetReflectionType(objectType, instance);
}
public override object CreateInstance(IServiceProvider provider, Type objectType, Type[] argTypes, object[] args)
{
if (objectType.FullName == typeof(TAbstract).FullName) // corrected condition here (original condition was incorrectly giving false in my case sometimes)
objectType = typeof(TBase);
return base.CreateInstance(provider, objectType, argTypes, args);
}
}就是这样！
您无需向未来的基于BaseForm的表单开发人员解释任何内容，他们也不必花任何技巧来设计表单！我认为这是最干净的解决方案（控件重新定位除外）。
另一个提示：
如果设计者出于某种原因仍然拒绝为您工作，则可以始终执行简单的技巧，将代码文件中的更改public class Form1 : BaseForm为public class Form1 : BaseFormMiddle1（或BaseFormMiddle2），然后在VS表单设计器中对其进行编辑，然后再次将其更改回。与条件编译相比，我更喜欢这种技巧，因为它不太可能忘记并释放错误的版本。
由于抽象类public abstract class BaseForm: Form会产生错误并避免使用设计器，因此我使用了虚拟成员。基本上，我没有声明抽象方法，而是以尽可能小的主体声明了虚拟方法。这是我所做的：
public class DataForm : Form {
protected virtual void displayFields() {}
}
public partial class Form1 : DataForm {
protected override void displayFields() { /* Do the stuff needed for Form1. */ }
...
}
public partial class Form2 : DataForm {
protected override void displayFields() { /* Do the stuff needed for Form2. */ }
...
}
/* Do this for all classes that inherit from DataForm. */由于DataForm应该使用抽象成员作为抽象类，所以displayFields我将这种行为与虚拟成员“伪造”在一起以避免抽象。设计师不再抱怨，一切对我来说都很好。
这是一种更具可读性的解决方法，但是由于它不是抽象的，因此我必须确保的所有子类都DataForm具有的实现displayFields。因此，使用此技术时要小心。
您可以有条件地在abstract关键字中进行编译，而无需插入单独的类：
#if DEBUG
// Visual Studio 2008 designer complains when a form inherits from an
// abstract base class
public class BaseForm: Form {
#else
// For production do it the *RIGHT* way.
public abstract class BaseForm: Form {
#endif
// Body of BaseForm goes here
}BaseForm如果没有任何抽象方法，则此方法有效（abstract因此关键字仅阻止类的运行时实例化）。