2009-11-21 16 views
14

Tengo una llamada de método en el constructor de mi control de usuario que hace algo que no funcionará en tiempo de diseño (conexión a una base de datos), y Visual Studio simplemente rescató cuando intenté agregar ese control al diseñador de la GUI.
Claro, puedo factorizar ese código a un método diferente, pero no me gusta la idea de que cada vez que uso ese objeto necesito recordar ejecutar cierto método que es esencial para la función de ese objeto (eso es lo que constructor es para!).¿Cómo tener código en el constructor que NO se ejecutará en el momento del diseño por parte de Visual Studio?

¿Hay algo así como un símbolo de preprocesador con el que pueda marcar mi código para que Visual Studio no intente ejecutar ese código en el momento del diseño?

+0

¿Es eso un buen diseño? IMO, uno no debe hacer demasiado (conectarse a la base de datos, en su caso) en el constructor. Me encantaría ver lo que los expertos tienen que decir. – shahkalpesh

Respuesta

26

Como otros han dicho, puede utilizar la propiedad DesignMode de la clase Component. Sin embargo, no podrá hacer esto en el constructor de su control. La propiedad DesignMode siempre es false en el constructor y los métodos invocados por el constructor. Para evitar esto, vuelva a factorizar su código para conectarse a la base de datos en la devolución de llamada OnLoad(). La propiedad DesignMode es válida en ese punto. Consulte here para el razonamiento (busque la sección DesignMode del artículo).

Acabo de encontrar este blog entry que describe cómo usar la propiedad System.ComponentModel.LicenseManager.UsageMode para hacer lo mismo. El blog describe una falla adicional de la propiedad DesignMode cuando se trata de controles anidados. Aparentemente, la propiedad UsageMode no tiene las mismas deficiencias y está disponible para su uso en el constructor. No puedo responder personalmente por ello, pero podría valer la pena investigarlo.

+0

¡La entrada del blog que vinculó funciona perfectamente para mí! (al menos hasta ahora) – polyglot

+0

Eso es bueno saber. Puedo aprovechar esa técnica la próxima vez que necesite un control personalizado. –

+6

El blog ahora está muerto, pero básicamente es simplemente: 'if (System.ComponentModel.LicenseManager.UsageMode == System.ComponentModel.LicenseUsageMode.Designtime)' – Gareth

10

¿En Windows Forms?

if (!DesignMode) 
{ 
    // code that shouldn't be executed at design time 
} 

Como otros han mencionado, esto no funcionará en el constructor. A menudo se usa en el evento Form.Load.

+3

Brillante, exactamente el mismo tiempo X-) –

+0

¡Rápido y directo al grano! Esperaba algún símbolo de preprocesador, ya que eso no afectará el programa después de la compilación, pero el impacto de este pequeño cheque es, por supuesto, mínimo;) – polyglot

+2

¡ten cuidado! La propiedad DesingMode tiene algunos problemas que deben tenerse en cuenta. Puede encontrar un artículo aquí: http://weblogs.asp.net/fmarguerie/archive/2005/03/23/395658.aspx – Beatles1692

0

Me gustó el enfoque de Michael Petrotta para Windows Forms. Si alguien quiere aplicar la misma técnica a WPF, simplemente use IsInDesignMode.

Ejemplo:

public SomeViewModel() 
{ 
    if (!IsInDesignMode) 
    { 
     DoWork(); 
    } 
} 
0
public SomeViewModel() 
{ 
    if (!IsInDesignMode) 
    { 
     DoWork(); 
    } 
} 

Este código de seguridad si se está trabajando en la interfaz de usuario real que usted está tratando de trabajar. En una situación en la que tiene algo como esto en un control, cuando vuelve al diseñador para ese control está bien y no hay error de tiempo de diseño. Ahora, si agregó ese control que contiene el código anterior a algún otro formulario u otro control arrastrándolo desde la caja de herramientas, mostrará algunos errores de tiempo de diseño.

Cuestiones relacionadas