Formularios Heredados.

"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.

Efectivamente eso es lo que quiero. Lo dejo como lo tengo ahora, un virtual y
override en la hija, seá la documentación la que avise de la declaración de
los métodos.

Muchar Gracias Alberto.

"Alberto Poblacion" wrote:

"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.

Gracias por tu interés.
Igual llevas razón en que estoy haciendo una burrada. La verdad es que no se
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.

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.

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.

Yo pienso que aún teniendo mucho sentido lo que pretendes hacer, no estás
explotando el uso de la herencia y polimorfismo que supone hacer cambios
(overrides) a sólo los comportamientos que cambian. Los que no necesiten
cambiar simplemente "heredan" el comportamiento de su clase base.



"Rafael Villaran. RAVIPE"
escribió en el mensaje
news:

Gracias por tu interés.
Igual llevas razón en que estoy haciendo una burrada. La verdad es que no
se
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.

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.