[ Foro de C# ]

Heredar formularios Winforms

26-Aug-2014 16:54
Jose Valdes Sirvent
14 Respuestas

Hay alguna forma fiable de heredar formularios en windows forms? Llevo una pelea bastante grande y no consigo hacerlo de forma satisfactoria.

Básicamente lo que quiero es tener una plantilla de "FormularioBase", y luego crear hijas que sean casi iguales a la base, con ligeras variaciones. Por ejemplo:
Creo un formulario base con varios textbox con el nombre del proveedor y datos de éste, y un listviewitem en el que aparecerán todas las lineas de factura.

En la hija "FormVerFactura", es la base, con todos los textbox rellenos y el data grid relleno y deshabilitados, y un boton que te llevaría al formulario "FormEditarFactura".

En la hija "FormEditarFactura", aparece todo relleno, pero habilitados, que habilitarían las modificaciones.

Y por último en el "FormNuevaFactura", aparecería todo vacío y con un botón "Guardar".

Pues bien, para realizar esto estoy teniendo muchos problemas con el tema de los constructores y tal.

En fin. Muchas gracias!


26-Aug-2014 21:03
Jose Valdes Sirvent

Me contesto a mí mismo.
Lo he conseguido. Pero realmente no tengo muy claro por qué me fallaba antes. Al final lo que he hecho ha sido crear solo la parte estética del formulario, y crear la hija que heredaba. Y luego he ido ya rellenando ambas partes hasta conseguir que funcione. Pero realmente.. no se qué podía estar fallando.. ¬¬

Un saludo!


26-Aug-2014 22:55
Jose Valdes Sirvent

Me contesto a mí mismo de nuevo.. Parece que el problema venía cuando el constructor de la clase base recibía parámetros, o cuando habían varios constructores en la clase base.. Ahora llevo ya toda la tarde trabajando con formularios heredados y la verdad es que de momento.. ningún problema!!

Un Saludo!!


27-Aug-2014 12:07
Nacho Cabanes (+83)

Eso te iba a decir... que en teoría debería funcionar sin problemas. Puedes encontrar alguna limitación menor pero esperable, como que en las clases hija no te aparezcan los elementos visuales heredados. Pero debería funcionar.

En cuanto al constructor de la clase base con parámetros, ten en cuenta que la clase Form no está creada por ti, sino que es parte del sistema básico, así que no será tan versátil como las que crees para ti. Además, el diseñador visual tiene que analizar su código fuente para mostrarte la parte visible de tu formulario, de modo que si complicas mucho la estructura quizá le "vuelvas loco".

Eso de clase base con parámetros me suena a que no lo estás haciendo de la forma óptima. Recuerda que lo ideal es separar la parte "visual" de la parte "de lógica de negocio", de modo que el coste de adaptar la aplicación a otra capa visual no se dispare. En esa parte (no visual) de "lógica de negocio" es en la que parece natural que las clases tengan múltiples constructores.


27-Aug-2014 12:15
Jose Valdes Sirvent

La verdad es que no se hasta qué punto estoy haciendo óptimo este programa a nivel de POO. Sobretodo porque mi anterior proyecto era en php y ahora estoy un poco descolocado.

Creo que no lo estoy haciendo perfecto, pero no obstante, creo que tampoco lo estoy haciendo demasiado catastrófico.

No estoy haciendo eso que dices de separar la parte de negocio de la gráfica.. No se exactamente a qué te refieres.

Por ejemplo: Tengo una especie de "inc_cabecera.php" como los que vimos en lenguaje de marcas contigo. En este caso es una clase "FormAmpliado", que hereda de form que tiene varios métodos que quiero que sean globales. Todos los formularios heredan de FormAmpliado en vez de de Form.
Métodos como Conectar(), Desconectar().. o por ejemplo como GetFactura(), que recibe un codigo de factura, y devuelve un objeto Factura, con todas sus líneas y tal.. para facilitarme el trabajo con la BDD.
O el contrario: GuardarFactura(), que recibe un objeto factura y lo guarda en la BDD.. todos esos métodos están en la clase FormAmpliado.
Y también en esa clase tengo las variables SQLiteConnection enlace, SQLiteCommand orden, y el string que es la ruta de la BDD..

Me sugieres alguna forma más óptima de hacerlo??

Un saludo Nacho! y como siempre.. gracias por todo!!!



27-Aug-2014 14:35
Nacho Cabanes (+83)

Deberías hacerlo en 3 capas, o al menos en 2, nunca sólo en una. No tiene sentido que cosas como un SQLiteConnection aparezcan en un formulario. Lo ideal es que el formulario pida datos a la clase Factura, y esta a su vez a la BaseDeDatos,

Así, tu clase principal es Factura (y las relacionadas). Si decides cambiar de base de datos, afectará poco (en teoría, debería ser "nada", si está bien pensado) a tu clase Factura y absolutamente nada a la parte visual. De igual modo, si necesitas otra interfaz visual distinta, las clases Facturas y BaseDeDatos no tendrían ningún cambio.

Si no es así, habrá código repetitivo, se complicará el mantenimiento, y el cambiar de base de datos o  de interfaz visual supondrá rehacer el programa casi por completo. Es menos grave de lo que parece, porque normalmente lo más importante es el "know-how", que ya tendrás, pero no deja de ser un trabajo enorme que se podría evitar con un diseño más cuidado.


27-Aug-2014 14:44
Jose Valdes Sirvent

Pues sí, tienes razón.. No obstante, creo que no está tan mal como tú crees. De todas formas supongo que no descarto, ahora que todavía voy por el 50% aprox del proyecto, rehacer muchas cosas..

Muchas gracias Nacho!!


27-Aug-2014 14:52
Nacho Cabanes (+83)

No digo que esté mal. Suena a ser una "buena primera aplicación con Windows Forms". Eso no quita que sea mejorable, sobre todo de cara a quitarte trabajo posteriormente en caso de tener que ampliarla o que usarla como base para proyectos similares.


27-Aug-2014 14:54
Jose Valdes Sirvent

Ya te la enseñaré ;)


28-Aug-2014 15:34
Jose Valdes Sirvent

Pues eso, ya he modificado tooooodo el programa. Me ha llevado toda la mañana hasta ahora mismo, pero ha merecido la pena..

Ahora todos mis formularios heredan del mismo FormAmpliado, pero ese solamente tiene funciones del tipo "ValidarNumero", "ValidarPrecio", y cosas asi.. Y lo que sí tiene, es un objeto BaseDeDatos.

Y esa clase base de datos tiene funciones del estilo "ObtenerFactura(string codigo)", que recibe un codigo de factura obtenido del formulario, y devuelve un objeto factura.. y cosas así. O incluso "ObtenerFacturasPorAnyo(int anyo)", que devuelve un array con todas las facturas de un año.

No se si esa es la forma que tú decías Nacho.. Si me dices que no me hundes!!! :P que vaya día de paliza llevo...!!


28-Aug-2014 22:19
Luis Torres (+18)

Disculpa, pero es que tengo la curiosidad por saber, ¿en tu universidad te enseñaron POO?


28-Aug-2014 22:46
Luis Torres (+18)

Disculpa, pero es que tengo la curiosidad por saber, ¿en tu universidad te enseñaron POO?


28-Aug-2014 23:23
Jose Valdes Sirvent

No estudio en una universidad, estudio en un instituto de formación profesional un módulo superior. Y sí, sí me enseñaron POO.


30-Aug-2014 01:29
Luis Torres (+18)

Disculpa que insista en la pregunta que ni siquiera tiene que ver con el problema que están tratando, pero ¿cuál es la diferencia entre un instituto de formación profesional y una universidad?


30-Aug-2014 22:11
Nacho Cabanes (+83)

Efectivamente, no tiene que ver.  ;-)

Lo paso a un hilo independiente y te contesto en él.






(No se puede continuar esta discusión porque tiene más de dos meses de antigüedad. Si tienes dudas parecidas, abre un nuevo hilo.)