DesignMode en el constructor

Hola Luisa ;-),

Prueba con:

if (System.ComponentModel.LicenseManager.UsageMode ==
System.ComponentModel.LicenseUsageMode.Designtime)

Nota: No sé si es el caso pero debes tratar de evitar poner referencias
externas en los controles. Ahora bien yo nunca he entendido por qué el
diseñador de forms de .NET para abrir el diseño de un control tiene que
ejecutarse parcialmente en vez de limitarse a comprobar simplemente los
tipos. Ahí está gran parte de la razón de estos errores tan incómodos.

Espero te sirva,

Saludos

Ricardo Passians



"Luisa Goicochea" escribió en el mensaje
news:%

Hola
quiero que una instruccion no se ejecute en DesignMode para evitar
producir unos molestos errores pero observo que si lo pongo en el
constructor de una clase, DesignMode siempre me devuelve false es decir
que no funciona.
Conocen de alguna alternativa?

Ohh... gracias!!!! me tenía loca ese problema.
Yo vengo de VB 6 y este .Net es como para volverse loca rapido jejeje

"Ricardo Passians" escribió en
el mensaje news:

Hola Luisa ;-),

Prueba con:

if (System.ComponentModel.LicenseManager.UsageMode ==
System.ComponentModel.LicenseUsageMode.Designtime)

Nota: No sé si es el caso pero debes tratar de evitar poner referencias
externas en los controles. Ahora bien yo nunca he entendido por qué el
diseñador de forms de .NET para abrir el diseño de un control tiene que
ejecutarse parcialmente en vez de limitarse a comprobar simplemente los
tipos. Ahí está gran parte de la razón de estos errores tan incómodos.

Espero te sirva,

Saludos

Ricardo Passians



"Luisa Goicochea" escribió en el mensaje
news:%

Hola
quiero que una instruccion no se ejecute en DesignMode para evitar
producir unos molestos errores pero observo que si lo pongo en el
constructor de una clase, DesignMode siempre me devuelve false es decir
que no funciona.
Conocen de alguna alternativa?

externas en los controles. Ahora bien yo nunca he entendido por qué el
diseñador de forms de .NET para abrir el diseño de un control tiene que
ejecutarse parcialmente en vez de limitarse a comprobar simplemente los
tipos. Ahí está gran parte de la razón de estos errores tan incómodos.

Para mi ese diseñador es horrible!

El Sat, 25 Oct 2008 20:30:59 -0400, Pedro escribió:

Para mi ese diseñador es horrible!

Pues el de WPF es muchísimo peor.

Para mi el diseñador está bastante bien, lo que está mal es la generación
de código.


Saludos

Para mi el diseñador está bastante bien, lo que está mal es la generación
de código.

Hola Alfredo, jejeje...

Para ubicar o posicionar los controles en el form el diseñador es muy bueno
pero, no se si estas cosas es que se configuran en algun lugar pero a mi me
pasan cosas por solo citar algunos ejemplos, que tengo una clase de Label
con la propiedad Autosize en true por defecto. Si meto a un form una
instancia de esa clase y para ese form le cambio el AutoSize a false, al
compilar el diseñador vuelve a ponerla a True. Hay que ir por codigo a
modificarla para que quede en false.
Tambien hay algunas propiedades de la instancia de una clase que uno no se
explica porque el diseñador las inicializa y sin tocarlas no asumen su valor
por defecto. Siempre hay que estar revisando la ventanita de propiedades
para ver si todas las que aparecen modificadas deben estar así o uno
hacerles un reset.
Tambien si uno da doble click sobre un control sin querer y te mete un
manejador de evento, si uno le da a deshacer a veces no solo borra el
manejador sino el ultimo objeto que metiste. O también si uno borra por
ejemplo un boton en un form que tenía ya un manejador del Click, te lo borra
pero te deja el codigo que se le habia puesto al manejador y hay que
borrarlo manualmente con el riesgo de olvidarlo.
Otras veces da un error en un form que se corrige simplemente cerrando el
Visual Studio y volviendolo a cargar, eso es para mi desastroso. Pero ese
error puede tener una opcion de Ignorar y continuar pero a veces uno le da a
esa opcion y el resultado es que se daña el form, borra algun objeto o algo
y hay que salir sin salvar y volver a entrar para que se quite ese error.
Otra cosa es que si uno crea un control que herede por ejemplo de textbox o
combobox (controles visuales) no hay forma primero de uno ver el control en
diseño ni de usar la ventana de propiedades para cambiar sus valores de
propiedades por defecto a menos que uno haga el truco de crearlo primero
como 'usercontrol' y luego cambiar por codigo el tipo de clase, en cuyo caso
tampoco se visualiza el control, lo cual no entiendo. Para .NET un
'usercontrol' solo debe ser visible en diseño cuando es un contenedor de
otros controles.
Y de los generadores de codigos de los datasets tipados ni hablar, la
cantidad de codigo innecesario que genera es sorprendente.
En fin, para mi no puede ser peor este diseñador, quizas es porque yo vengo
de Visual Foxpro 9 donde si bien el posicionamiento de controles no era muy
bueno ni amigable pero no vi ninguno de esos otros problemas e inestabilidad
del de .NET. De hecho uno ni veía el código que generaba el diseño porque
lo hacía a bajo nivel y no había necesidad de preocuparse por él.







"Alfredo Novoa" escribió en el mensaje
news:13g5iq0vjuisx.px23pq521ksh$

El Sat, 25 Oct 2008 20:30:59 -0400, Pedro escribió:

Para mi ese diseñador es horrible!

Pues el de WPF es muchísimo peor.

Para mi el diseñador está bastante bien, lo que está mal es la generación
de código.


Saludos