Pasar parametros a una ventana

[lucasarts_18]

Lepe:

Gracias por tu aporte, pero después de unas copitas de vino no creo que pueda analizar bien tú código, prometo mañana echarle un vistazo

Nos vemos...

[[Lepe]]

Reconozco que al verlo por primera vez impresiona un poquito, veamos el concepto, y así de camino sirve para otros foristas:

Código Delphi [-]
 property Param1:string read Fparam1 write Fparam1;

¿Qué es FParam1?
Simplemente una variable privada del mismo tipo de datos que Param1. Se podría decir que es una "Copia de seguridad" de la propiedad.

¿Por qué se llama FParam1?, es un estándar, a todos los campos (Fields) que son privados de una clase, se le añade la letra "F" al principio.

¿Por qué no hacerlo así:

Código Delphi [-]
public
  Param1:string;

Porque si tenemos que modificar la clase por otros detalles, estamos utilizando la variable pública Param1, y puede incluso que necesitemos cambiar el tipo de datos, esto supone que los programas que usan esa clase también necesitan modificarse. Esto es una onda expansiva, igual que tirar una piedra en el lago, las modificaciones se van propagando y al final necesitas rehacer todo el programa.

Al usar una variable pública y otra privada, se pueden hacer cambios en el interior de la clase y no modificar la variable pública. No hay onda expansiva .

Código Delphi [-]
// desde fuera de la clase, hacemos uso de ella:
ShowMessage(Form1.Param1)

Con esa linea estamos leyendo (read) el valor de Param1, en realidad delphi, lee el valor de la variable FParam1.

Código Delphi [-]
// desde fuera de la clase, hacemos uso de ella:
 Form1.Param1 := 'hola mundo';

En este caso estamos escribiendo (write) en la variable, por tanto delphi asignará a FParam1, el valor 'hola mundo'.

La otra variante que lleva dos procedimientos, es exactamente igual, solo que ahora en lugar de leer de una variable privada, se ejecuta una función (GetParam1) que devuelve un string. También al tiempo de asignar una variable, se usa un procedimiento (SetParam).

"Get" y "Set" también es un estándar, son prefijos que siempre se añaden para hacer más legible el código.


Saludos

[roman]

Empezado por Lepe

Porque si tenemos que modificar la clase por otros detalles, estamos utilizando la variable pública Param1, y puede incluso que necesitemos cambiar el tipo de datos, esto supone que los programas que usan esa clase también necesitan modificarse. Esto es una onda expansiva, igual que tirar una piedra en el lago, las modificaciones se van propagando y al final necesitas rehacer todo el programa.

La onda expansiva no se detendrá si cambias el tipo de datos. Por lo demás estoy completamente de acuerdo con lo que expones y en mi opinión es el camino más adecuado.

El uso de un método para paso de parámetros puede ser útil en ciertas circunstancias pero muchas veces terminamos teniendo métodos con una lista interminable de parámetros. Uno sigue teniendo pleno control del formulario al momento de crearlo, aunque, de hecho, no entiendo esto:

Empezado por Epachsoft

De esta manera se evita la MALA costumbre de poner codigo en el OnShow, en el OnActivate

¿Por qué es mala costumbre?

// Saludos

[Epachsoft]

Yo en lo personal me iria mas por hacer un "overload" o "override" del metodo execute, tal como se hace con el "creator" o el "destructor", dependiendo de la necesidad. Modificando los parametros de entrada si eso es lo que se busca.


Mis problemas con OnActivate
- Se activa cada momento en que la ventana obtiene "focus", si usted trabaja con multiples ventanas, este evento y el codigo dentro del mismo se ejecutara multiples veces al hacer switch, no una ves, a como es usualmente deseado en un metodo de ejecucion tipo "execute".

Esto se puede eliminar agregando variables internas para controlar la primera vez que se logra la activacion y asi en adelante no re-ejecutar las instrucciones en este evento, pero en fin, mas codigo.

No hay nada de malo con Onshow, pero en lo personal, para valores de inicializacion y de ejecucion de nuevos dialogos, OnShow es un evento que ocurre ya muy tarde en el ciclo de ejecucion de una nueva ventana. No permite inicializar variables visuales y no visuales que se necesitan previo al despliegue de una ventana. En fin, es el gusto de cada cual, en lo personal para un metodo de ejecucion de una ventana o dialogo, muy raramente usted vera codigo creado alrededor del evento OnShow.

El VCL muestra muchos ejemplos de esto, raramente OnShow es utilizado internamente.

[roman]

Empezado por Epachsoft

Mis problemas con OnActivate
- Se activa cada momento en que la ventana obtiene "focus", si usted trabaja con multiples ventanas, este evento y el codigo dentro del mismo se ejecutara multiples veces al hacer switch, no una ves, a como es usualmente deseado en un metodo de ejecucion tipo "execute".

No entiendo por qué eso es lo deseado; estamos hablando de OnActivate, y tal es el comportamiento documentado. Si no es eso lo que se quiere entonces se usa otra cosa, pero eso no quiere decir que el evento no sea adecuado o que sea mala práctica poner código ahí.

Empezado por Epachsoft

No hay nada de malo con Onshow, pero en lo personal, para valores de inicializacion y de ejecucion de nuevos dialogos, OnShow es un evento que ocurre ya muy tarde en el ciclo de ejecucion de una nueva ventana. No permite inicializar variables visuales y no visuales que se necesitan previo al despliegue de una ventana.

Como bien dices, es una cuestión personal. Yo uso sin ningún problema este evento para inicializar (no construir, que para eso está OnCreate) cuestiones visuales como etiquetas, por ejemplo. Es cierto que hay cosas que conviene hacer antes de mostrar (Show/ShowModal) el formulario, pero eso sólo indica que para ciertas cosas, dicho evento no es el adecuado, de ninguna manera significa que sea mala práctica per sé.

Empezado por Epachsoft

El VCL muestra muchos ejemplos de esto, raramente OnShow es utilizado internamente.

Es que, de hecho, difícilmente verás ningún evento utilizado internamente, no es exclusivo de estos eventos, simplemente porque éstos, los eventos en general, están pensados para el programador final, la VCL sólo los pone disponibles.

// Saludos

[Epachsoft]

"Es que, de hecho, difícilmente verás ningún evento utilizado internamente, no es exclusivo de estos eventos, simplemente porque éstos, los eventos en general, están pensados para el programador final, la VCL sólo los pone disponibles."

Incorrecto, en gran parte de la VCL se usa por herencia los metodos OnCreate, OnChange, OnKeyDown, etc, seria mas bien extrano decir que se puso ese evento unicamente para el usuario final.

El VCL no es simplemente una cosa bonita que Borland puso ahi, es un claro ejemplo de la forma correcta de desarrollar codigo usando Object Pascal, desde su sintaxis, best "coding practices", comentarios y estandarizacion de presentacion de codigo.

Es un ejemplo en vivo de como implementar todo tipo de soluciones, e.g. una caja de dialogo donde se despliega un mensaje (MessageDlg), un wrapper de Activex, etc, codigo que usaremos muchas veces en situaciones de nuestra vida diaria. Solo examinen la implementacion de los DBAware components y noten como gracias a toda esa base de clases, metodos y con gran uso de herencia y polimorfismo logran implementar esos increibles componentes.

Danny Thorpe, antiguo chief scientist de Borland y la persona a cargo del compilador de Delphi escribio el maximo manual de como escribir componentes, dialogs, etc en Delphi, utilizando como ejemplo el mismo VCL y la mayoria de sus metodos. Es una gran lectura, y un libro considerado como clasico.

----

Ahora bien por el otro lado, repito, no utilicen el OnShow event para inicializar variables. Si estan haciendo aplicaciones pequenas para la casita, con par de formas y que solo ustedes van a hacer perfecto, pero si es para aplicaciones serias donde se utiliza mucha herencia, formas MDI y Frames, poner eventos en el OnShow o en el OnActivate SOLO les va a traer problemas y dolores de cabeza. Inicializacion !!NO!! en ese evento. Usen Oncreate, o pongan un metodo execute. (Noten como la mayoria de Dialogos en Delphi (revisen tambien los componentes JEDI) tienen un metodo Execute y pocas veces codigo en OnShow.

Muchas gracias.

[roman]

Empezado por Epachsoft

Incorrecto, en gran parte de la VCL se usa por herencia los metodos OnCreate, OnChange, OnKeyDown, etc, seria mas bien extrano decir que se puso ese evento unicamente para el usuario final.

Incorrecto, lo que se usa son los métodos virtuales correspondientes como Show.

Empezado por Epachsoft

El VCL no es simplemente una cosa bonita que Borland puso ahi, es un claro ejemplo de la forma correcta de desarrollar codigo usando Object Pascal, desde su sintaxis, best "coding practices", comentarios y estandarizacion de presentacion de codigo.

Y ¿quién ha dicho lo contrario?

Empezado por Epachsoft

Si estan haciendo aplicaciones pequenas para la casita, con par de formas y que solo ustedes van a hacer perfecto,

¡Vaya arrogancia la tuya! Con esto cierras cualquier posibilidad de diálogo.

// Saludos

[[Lepe]]

Empezado por roman

La onda expansiva no se detendrá si cambias el tipo de datos.

Ese punto no lo expliqué como quería.

Si tenemos el método Get (ya hablando con propiedad), podemos tener la propiedad pública de tipo String, pero usar un campo privado de tipo entero. En el métodos Get se hacen las conversiones oportunas para devolver un string.

De esta forma se mantiene el tipo de datos de la propiedad pública, pero se ha cambiado el tipo de datos del campo privado.

¿para qué hacer algo así?, bueno, quizás haya que devolver "331 Pepe Martínez", donde el 331 es el código de cliente y después el nombre, quizás interese guardar como entero el 331 para uso interno. (solo es un ejemplo ).

Saludos

[roman]

Empezado por Lepe

De esta forma se mantiene el tipo de datos de la propiedad pública, pero se ha cambiado el tipo de datos del campo privado.

Ya veo. Entonces estoy 110% de acuerdo con tu método.

// Saludos