destruir formularios en .net

2 consejos:

• no olvides que existe el metodo "closing" aunque no este referenciado en metodos propios del form. No hace falta hacerle un Handler.

• Te diria que crees una funcion externa personal que sea la que se llama en el OnLoad, de esta manera, te "liberas" de la necesidad de volver a cargar el formulario para ejecutar el codigo que hay en el OnLoad, y sencillamente tienes independencia pudiendo llamar siempre que quieras a la funcion. Es decir:

OnLoad:

"hello world".

Pasaria a:

Func HelloWorld:

"Hello world".

OnLoad:

call HelloWorld.

y siempre que quieras, llamas al hello world.
Es basico y lógico, pero en VB muchas veces olvidamos lo que significa trabajar con programación sequencial... xD

#3

touche

Un consejo... C# por dios...

using(myFormulario f1 = new FmyFormulario)
{
    f1.ShowDialog();
}

El envoltorio using funciona con cualquier tipo que implemente la interfaz IDisposable y automatiza su destrucción.

Por otra parte, Form expone el metodo Close(), para cerrar y destruir un formulario.

YOK3S3 yo de ti editaria una vez mas el post.

Mas que nada porque VB y C# trabajn sobre el mismo CLR.

Gracias por sentirte tan superior.

Sin entrar en framworks externos, hay poquisimas cosas que no se puedan hacer con VB respecto de C#.

Si NHibernate no esta bien programado no es problema del end-programmer, ya que no veo la utilidad de forzar un lenguaje de programacion, cuando .NET precisamente lo que busca es pasar de los lenguajes para tirar al CLR directamente, diseñando los compiladores para que el mismo codigo en diferente lenguaje den el mismo CLR.

PD: Tiene buena pinta esto del modelo relacional de objetos. Habra que hecharle un ojo.

#10 Q me quieras timar:
NHibernate is a port of Hibernate Core for Java to the .NET Framework.

Desconozco NHibernate, y la verdad porque yo use ADO.NET, que viene de serie con el framework de .NET y tu utilices eso de NHibernate no te hace ser mejor programador q nadie. Además, que me parece absurdo q me compares un software a lo q yo te he dicho de q un codigo en VB pasa a C# y viceversa.

Enchufa el reflector, decompila lo quieras y pasalo de C# y VB y viceversa.

Y baja esos humos de welcome to real world, q yo llevo trabajando muchos años con .NET, desgracidamente

#12 No, he observado q con un click en el MSDN cualquier codigo pasa de C# a VB y el único motivo de usar C# es venir acostumbrado de la sintaxis de C y C++, igual q el q utilice VB.NET, lo utilizará porque venga acostumbrado de la sintaxis de VB y el q venga de Java utilizará J#.

Tan simple como eso, ninguno es superior a otro porque precisamente esa es la gracia del .net framework.

Y como ya te he dicho, ser supremo del "Nhibernate", coge cualquier ejecutable, dll o lo q quieras desarrollada en .NET, abre el reflector y decompilala, verás como te deja pasarla a sintaxis de VB o C# sin problemas.

#13

Hay cosas nuevas que solo estan en c#...Pero bueno.

La verdad es que estoy mirando a ver si vació todos los textbox "a mano" o "descargo" de memoria el formulario entero todavía lo estoy viendo.

El uso de Visual Basic es, simplemente es que me llevo mucho mejor con el entorno a la hora de programar, y he salido de muchos apuros con el.
De todas formas son los dos de Micro$oft.
Puesto que visual Studio 2005 tengo entendido que deja migrar de uno a otro tenia pensado hacerlo en Visual Basic y luego, si acaso pasarlo a C# y verificarlo después.

la verdad, para un PFC queda mucho mejor C# que VB.net, aunque sean lo mismo.

PD:
Una pregunta a riesgo de parecer ignorante......
Que es Nhibernate? xD
Y el reflector ese para que sirve?

Gracias por la info.

#18 muchas gracias por la info

tengo que hacer un servicio web (todavia no se como) para comunicarse con mi programa y transmitir ficheros xml (generados a partir de una consulta a una bd) con la respuesta, asiesque no os extrañe que vuelva a preguntar xD

Buscaré info sobre NHibernate xD

Pero tan parecido es el C# al VB?
Mira que le tengo algo cojido que no se...

Basicamente se deja hacer todo, esto lo tengo claro pq algunas cosillas he hecho, pero que tal al gestion de forms tal como lo hace VB? Se deja programar igualmente?

No se macho, es que tengo leido por ahí que C# no es tan magnifico como parece, de hecho, parece que es una cosa guarra guarra...

Como lo veis?
Y en contrapunto, porque no seguir con C++?
Puedo programar como lo haria en C++ en C#? Exactamente igual?
Que tal se conporta con librerias externas como Glut o VTK? Se pueden importar de la misma forma?

Dadme algun motivo evidente del porque deba destinar mi atención al # y no seguir con el ++, please...

Esq tengo un proyectillo entre manos, y debo decidir si tirar por Java, C# o C++ y los tres me tienen asqueado, ya que deberemos programar para algo bastante "especial"...

Help please

#21

Lo único q tienen en común C# y C++ son la C eh? En serio, te pongo el ejemplo más fácil, en C# no existen punteros ni direcciones de memoria y por supuesto, no conozco esas librerias pero si están desarrolladas para C++ no se van a poder importar en C#, son dos lenguajes de programación que no tienen nada q ver. Simplemente Microsoft le llamó C# porque copió la sintaxis de C y C++.

Por ejemplo, en C# un entero también se define como "int a;".

Si el proyectillo es un programa de gestión de alguna empresa, tira por C# o VB.NET porque el ADO te simplifica la vida. Si no quieres q te decompilen el codigo, no lo uses, porque aunq el obfuscator te ayuda algo, no deja de transformar "int i; i=1; i=j+2" a "a b; a = 1; a=c+2;" y con un poco de paciencia se sacan trozos de codigo también.

Java lo utilizaría si buscas portabilidad a Linux, además de q tiene 9392392132 componentes gratuitos (.NET tb los tiene, ojo, pero los mejores son de pago). No se si el código se decompila tan fácil como en .NET.

C++ lo utilizaría cuando lo demás se te queda corto. Hay veces que necesitas trabajar con accesos a memoria y cosillas así. Me parecería una locura desarrollar por ejemplo un programa q acceda a una base de datos en C++, ya que con los 2 anteriores lo haces de una forma más sencilla y sin tener q preocuparte de q se t e ha olvidado poner un puntero o una dirección de memoria.

Sobre el uso de C# o VB.NET, yo también estoy de acuerdo de q C# se utiliza más. Creo que todos estaremos de acuerdo a qe se debe a su sintaxis similar a C y C++.

Llamar addon a Nhibernate del .NET es como llamar a un video addon de una tele.

No es una simple dll de ASPMAIL...

Nhibernate te une a tecnologias como IoC y DI que implementan por ejemplo dentro de las tecnologias/soluciones del CastleProject.

Tanto el Nhibernate como el Castle son OpenSource y tiene una comunidad enorme detras.

Ahora reiros todo lo que querais y seguir usando ADO.Yo me quedo con mi IoC/Di (MicroKernel/Winsord.Contair) y mvc (Monorail).

#26

Aun asi la peña dice que el Vb.Net es la polla en vinagre.

pd: Yo me pase del vb.net al c# por algo.

#26 No se, si tu puedes llamar con pinvoke una libreria q utilicé en el proyecto de fin de carrera para Borland C++ para utilizarla en Visual C# ole tus cojones, yo no soy capaz ^^. Pero bueno q a lo mejor se puede, cosa q dudo pq es mezclar churras con meninas, pero yo tenia entendido q Pinvoke se utilizaba para llamar a dlls de API de windows.

Ah, y me parece una locura recomendar Addons de pago para programar, entre otras cosas porque no todas las empresas os van a dar el gusto de poneros las licencias q necesitais, al menos yo le digo a mi jefe q me de dinero para comprar una licencia de resharper y se parte en mi cara XDD.

#27 Nadie dice q VB.NET es la polla en vinagre, solo digo q es lo mismo q C# con sintaxis de VB, en vez de con sintaxis de C. Yo al menos lo utilizo indistintamente y jamás he tenido problemas.

Por cierto, paso de seguir con este off topic del post.