c# - sobreescritos - VisualStudio 2010 Designer recurre al método virtual implementado

que es una clase virtual c#

Question

Quiero tener un UserControl abstracto, BaseControl , que implemente una interfaz IBaseControl . Sin embargo, al configurar la clase para resúmenes abstractos Diseñador VisualStudio (Este es un problema conocido con Visual Studio (por ejemplo, ver esta publicación de StackOverflow para más información), y hasta donde yo sé, no se esperan cambios en el futuro cercano.

Entonces, para evitar esto, hago que BaseControl no sea abstracto, y su implementación de los métodos de IBaseControl virtual. Sin embargo, dado que estos métodos no tienen sentido para un BaseControl (por ejemplo, no se han agregado todos los componentes aún), los hago lanzar:

public class BaseControl : UserControl, IBaseControl
{
/// <summary>
/// This IBaseControl method is not abstract because
/// that breaks the Designer
/// </summary>
public virtual void LoadSettings()
{
throw new NotImplementedException("Implement in derived class.");
}
private void BaseControl_Load(object sender, EventArgs e)
{
// intention: derived methods automagically load their settings
this.LoadSettings();
}
}

En el control derivado, tengo la anulación correspondiente:

public partial class DerivedControl : BaseControl
{
public override void LoadSettings()
{
// load settings
}
}

A pesar de esto, cuando intento abrir el control en el diseñador, BaseControl.LoadSettings un error que indica que BaseControl.LoadSettings ha lanzado una excepción.

Ahora, recuerde que se llama a LoadSettings en la clase base, de modo que cuando el Diseñador carga el DerivedControl , a su vez llama al método de carga para BaseControl , que arroja.

¿Has encontrado un problema similar? ¿Cómo has lidiado con esto? Me gustaría tener una solución elegante, si es posible.

Answer 1

¡La razón por la cual se lanza la excepción es porque, curiosamente, el diseñador no compila ni instancia la clase que está diseñando en absoluto ! Solo compila e instaura la clase base del control que está diseñando.

Por qué este es el caso se vuelve obvio cuando te das cuenta de que agregar nuevos subcontroles al elemento requeriría una mayor recopilación. Además, cada controlador de eventos que agregue modifica la clase y de nuevo requerirá recompilación. Como los controladores de eventos nunca serán llamados en el diseñador de todos modos, esto es completamente innecesario. Diseñas con una clase que se parece a tu clase pero no es tu clase; Es un trabajo en progreso.

Como solo se crea una instancia de la clase base, la clase base no puede ser abstracta y debe ser funcional tal como está . Si arrojas excepciones, el diseñador las verá. La única solución práctica es:

• No arrojar excepciones de la clase base, o
• Condicionalmente no se lanzan excepciones en función de si se trata de tiempo de diseño o no.

Cualquiera de los dos funcionará; utilice el que prefiera o que funcione mejor para su diseño. Así es como funciona el diseñador y, como usted menciona, no es probable que cambie.