DesignMode en el constructor

24/10/2008 - 13:40 por Luisa Goicochea | Informe spam
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?

Preguntas similare

Leer las respuestas

#11 Juan Diego Bueno
26/10/2008 - 14:46 | Informe spam
Totalmente de acuerdo contigo, Pedro. A mi me pasan el 90% de las cosas que
planteas y te vuelves loco hasta dar con la solución.

Un coñazo, vamos... para que nos entendamos.

Un saludo


"Pedro" escribió en el mensaje de
noticias:
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




Respuesta Responder a este mensaje
#12 Pedro
26/10/2008 - 15:06 | Informe spam

Un coñazo, vamos... para que nos entendamos.




:) se entiende claro!

Saludos
Respuesta Responder a este mensaje
#13 Alfredo Novoa
26/10/2008 - 17:25 | Informe spam
Hola Pedro,

El Sun, 26 Oct 2008 09:11:22 -0400, Pedro escribió:

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.



Pues a mi eso me funciona, aunque a veces da guerra y tengo que cerrar el
VS y volverlo a abrir para que me haga caso si hago cambios en los
controles.

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.



A mi esto tampoco me pasa.

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.



A mi me parece bien que no lo borre. Lo que no me gusta es que cuando
borras el "manejador" no te borra automáticamente la asignación del
delegado como hacía Delphi y hay que ir a borrarlo a mano.

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.



A mi me pasa mucho. Y otras veces aun peor por que se corrompe el código
generado por el Visual Studio y tengo que arreglarlo a mano. Ahora ya se
encontrar rápido donde tengo que tocar, pero las primeras veces me volví
loco.

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.



Es mejor no darle a ignorar.

Y de los generadores de codigos de los datasets tipados ni hablar, la
cantidad de codigo innecesario que genera es sorprendente.



Ya, pero todo esto que comentas no es del diseñador própiamente dicho sino
de la forma en la que los diseños se hacen "persistentes". El diseñador lo
podemos utilizar en nuestros propios proyectos y grabar los formularios
como nos de la gana y no tenemos por que tener ninguno de estos problemas.

Uno de los muchos proyectos que tengo aparcados por falta de tiempo es
hacer un IDE que guarde los formularios y el código en una base de datos.

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.



Ya, lo de la generación de código es una mala idea como en los ORM. La idea
de WPF es mucho mejor pero el diseñador está muy verde y no hay controles
decentes para hacer aplicaciones de gestión.


Saludos
Respuesta Responder a este mensaje
#14 Luisa Goicochea
27/10/2008 - 17:32 | Informe spam
Yo creí que problemas parecidos me pasaban a mi debido a que soy nueva en
.NET pero con todo lo que mencionas no tengo mas que sorprenderme y
preocuparme por lo que me espera :(
Gracias por compartirlo



"Pedro" escribió en el mensaje
news:
>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




Respuesta Responder a este mensaje
#15 Hugo Nugra
27/10/2008 - 22:47 | Informe spam
"Luisa Goicochea" wrote:

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?





Utiliza la propiedad DesignMode (de tipo bool) Si estás en tiempo de diseño
será tue.
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida