Formularios Heredados.

On Tue, 21 Apr 2009 11:42:01 +0200, Rafael Villaran. RAVIPE
wrote:

> Gracias por tu interés.
> Igual llevas razón en que estoy haciendo una burrada. La verdad es que
> no se

Cuando he dicho burrada lo he dicho en referencia a mi solución propuesta,
no a tu requisito, que tiene cierta lógica en cuanto a la petición, pero
no en cuanto a por qué quieres algo así.

> me ocurre otra forma. La idea es que como sabes la mayoría de los
> formularios, como poco el mantenimiento de ficheros auxiliares o maestro,
> lleva mucho código común :
> - comprueba si se ha pulsado tecla,
> - el estado modificado o no,
> - comprobar este estado al salir,
> - activar los botones guardar y deshacer,
> - los métodos correspondiente a los botones anteriores y de salir.
>
> En fin una serie de código repetitivo que con esto a mi me funciona
> perfectamente. Únicamente me dedico a montar los controles y métodos
> propios
> del fichero concreto y ya está, el mantenimiento realizado. El problema
> viene
> cuando antes de salir tienes que comprobar al, por ponerte un ejemplo.
> En el
> base únicamente compruebo el estado del form si está o no modificado, en
> el
> padre actuo según necesidad. En fin, no dudo que exista otra forma, pero
> como
> seguramente has leido en algunos mensajes anteriores, me gusta
> complicarme la
> vida. Tampoco lo veo de otra forma.
>

Es que lo que quieres hacer tiene otra solución si te he entendido bien
(yo de validaciones de bases de datos y todo eso, sé poco o nada, cuando
murió Clipper dejé el tema). Si lo que quieres hacer es validar botones y
reglas de las fichas, lo puedes hacer siempre y cuando "desciendas un
nivel". Yo eso lo hacía en C++ Builder.

Te creas una ficha base con los botones que vayas a necesitar, incluidos
aquellos que sólo estarán disponibles en las hijas. Luego defines los
métodos de validación, que ejecutarás donde y como quieras.

Las clases hijas tendrán esos botones visibles o no, o con algún valor
concreto en el Tag de los mismos. La función de validación irá recorriendo
los botones y realizará reglas en cuanto a si el botón (o lo que sea) está
visible o bien tiene un valor concreto en el Tag.

La cosa puede crecer hasta el punto de tener "reglas definidas por Tag".
Algo así:

enum Reglas
{
NoDebeSerCero,
EsDefecto,
PintarDeRosa,
...
};

Luego te defines un método que recorra todos los controles de la ficha y
si el Tag es uno de ellos, hará la validación adecuada. Si necesitas
varias validaciones en cadena, puedes asociar una lista al Tag...

Y ya de paso hacer como hacía yo en Clipper en mis tiempos: tenía un
fichero de campos/reglas/bloques de código y construía de forma dinámica
los formularios a partir de esos campos y bloques de código asociados, sin
necesidad de herencia (que no la había) ni polimorfismo (que tampoco lo
había). Y en esto .NET se parece mucho a Clipper: puedes almacenar bloques
de texto que luego podrás compilar y ejecutar al vuelo, y con el sistema
de reflexión es relativamente fácil construirte un sistema completamente
dinámico que se cree a sí mismo en tiempo de ejecución a partir de una
serie de tablas y ficheros. Y digo relativamente porque hacerlo es
bastante complejo, pero si en Cipper yo lo tenía, en .NET es bastante más
fácil de hacer.

> De todas formas nunca me canso de agradeceros a todos la ayuda que
> prestáis
> en el foro, y por supuesto te agradezco la tuya y tus comentarios.
>
> Un saludo.
> rafael villarán.
>
> "RFOG" wrote:
>
>> "Alberto Poblacion"
>> wrote
>> in message news:
>> > "Rafael Villaran. RAVIPE"
>>
>> > wrote in message
>> > news:
>> >> Efectivamente es un formulario win. Imáginate. Le pongo un botón de
>> >> comando.
>> >> En el evento click llamo a un método, el que quiero reescribir en el
>> >> hijo,
>> >> que realiza una serie de acciones dentro del base y me devuelve true
>> o
>> >> false
>> >> según respuestas del usuario. Este es el método que dentro del hijo
>> debo,
>> >> o
>> >> mas bien puedo reescribir, si lo necesito. Además este sería el
>> método
>> >> que si
>> >> no lo tiene el hijo, me gustaría me avisase para que al menos lo
>> defina,
>> >> aunque no ponga código.
>> >
>> > Si lo he entendido bien, lo que quieres es en la clase hija poder
>> hacer
>> > un override, que no sea obligatorio, pero que si no lo haces te de un
>> > Warning. ¿Es eso?
>> > Pues en ese caso, me temo que la funcionalidad nativa de C# no te
>> lo da.
>> > Solo te da la posibilidad de marcar el método como virtual, en cuyo
>> caso
>> > es opcional hacerle un override, pero no da ningún aviso si no lo
>> haces. O
>> > marcarlo como abstracto, en cuyo caso es obligatorio hacer el
>> override y
>> > te da un error si no lo haces. No hay una opción intermedia.
>> >
>>
>> Ni en C# ni en C++ ni creo que en ningún otro lenguaje orientado a
>> objetos.
>>
>> Aparte de que no le veo lógica a lo que quiere hacer, lo entiendo
>> perfectamente pero no veo coherencia en ello.
>>
>> De todos modos se me ocurre una burrada que lo mismo puede funcionar
>> pero
>> con serias penalizaciones de rendimiento, y sólo válido en tiempo de
>> ejecución (si el preprocesador de C# hubiera sido algo más potente
>> quizás
>> también en tiempo de compilación). Se trataría de, mediante reflexión,
>> en el
>> constructor, enumerar todo los métodos de la clase y comprobar si son
>> propios o heredados -que supongo habrá alguna forma de hacer (*)- y si
>> son
>> heredados, lanzar una excepción. Así, al menos en tiempo de ejecución
>> (se
>> podría hacer una prueba unitaria o como se llame, con lo que todo
>> quedaría
>> en casa), se podría comprobar.
>>
>> Ampliando el tema, quizás se podría tener una base de datos embebida en
>> código (una clase estática que contenga un array con los nombres de los
>> métodos a comprobar, por ejemplo) y sólo comprobar estos.
>>
>> Y otra opción mejor: hacer un pre-compilador (como tienen las QT para
>> los
>> slots y las signals en C++) y definir una regla de precompilación que
>> pase
>> la clase por dicho pre-compilador y que salte en caso de no cumplir la
>> regla.
>>
>> De todos modos, es una burrada tanto de diseño como de implementación,
>> pero
>> la reflexión está ahí para ser usada (aunque no fuera ese el motivo de
>> su
>> creación).
>>
>> (*) Si no existe una forma directa, se podrían listar los métodos de la
>> clase actual y los de la padre, e irlos comparando uno a uno y si hay
>> alguno
>> de los que nos interesa que esté en la padre pero no en la actual,
>> lanzar la
>> excepción.
>> Microsoft Visual C++ MVP
>> ==> >> Mi blog sobre programación: http://geeks.ms/blogs/rfog
>> Momentos Leves: http://momentosleves.blogspot.com/
>> Cosas mías: http://rfog.blogsome.com/
>> Libros, ciencia ficción y desarrollo
>> > >> Por lo que uno tira, otro suspira.
>>
>>
>>