Ámbito de las variables usadas en un formulario

[Miguel A.]

Hola,

A raíz de este debate https://groups.google.com/forum/#!topic/publicesvfoxpro/iqdEqKTwMws en el que las variables públicas tal parece que son la peste porcina, me gustaría que me aclarasen qué ámbito tienen las variables dentro y fuera de un formulario, dependiendo de cómo se declaren; y también dónde hay que declararlas dentro del Form.

En concreto he observado dos problemas:

- Si se declara una variable LOCAL en Load, por ejemplo Principio=.t., en el Activate del Form dice que esta variable no está definida; mientras que si se declara como PUBLIC la reconoce perfectamente.

- El segundo caso es cuando hay una llamada a un .prg desde el Form, o cuando hay un retorno de variables a un estadio anterior a la llamada a ese Form (este caso ya se vio en el hilo anteriormente citado).

Encantado de saludarles,

Miguel A.

[Antonio Meza]

Hola Miguel!! no te respondo tu pregunta, solo comento la realidad sobre el tema.

El desconocimiento generalizado en Internet sobre los conceptos básicos de programación, las buenas practicas, reglas, patrones de diseño, interfaces,normalizacion de base de datos relacionales, etc, etc, provocan que existan infinidad de debates sobre muchos temas, pero realmente es por DESCONOCIMIENTO, no es porque realmente exista un debate real, si no que una mayoría desinformada cree que tiene la razón sobre una pequeña minoría bien preparada y estudiada.

Imagina que un 90% tiene desconocimiento generalizado, y empiezan a publicar en Internet en blog, foros, revistas, libros, como hacer uso de las variables Publicas, entonces para una persona que apenas comienza lee sobre el tema y dirá que es el camino correcto puesto que la mayoría así lo usa, usar todas las variables publicas que se necesiten, total es mas fácil y rápido y funciona, que es lo que la mayoría se preocupa que solo funcione sin importarle bajo que costo.

Lastimosamente no es lo correcto, existe una minoría (por continuar con el ejemplo) de solo un 10% que aplica todo en global las mejores practicas de programación, y te dirán que trates de no usar variables Publicas pues no es una buena practica, y te abrían un abanico de conceptos que tal vez nunca hayas escuchado y se te hará mas difícil de entender posiblemente, pero que es el camino correcto.

Si de 100 personas 90 te dijeran que uses variables publicas a diestra y siniestra y que solo 10 personas te dijeran que no es lo correcto, por lógica dirás que la mayoría tiene la razón y por lo tanto si la mayoría lo usa tu porque no!!!

Programar para la mayoría solo es tirar lineas de código para obtener un resultado, para muy pocos (en mi caso) es un arte, donde cada detalle importa.

Tenemos la fortuna de contar con grandes programadores en este foro que a demás de enseñarnos se toman el tiempo para explicarnos las buenas practicas, ya esta en cada quien el cambiar y mejorar o solo ser parte del montón. En mi caso era parte del montón jajaja, pero desde hace unos cuantos años abrí los ojos y es un camino complicado pero vale la pena, solo es cuestión de dejar los malos hábitos, estudiar, estudiar, practicar y aplicar las buenas practicas.

En conclusión no hay un debate sobre este tema y muchos otros, solo es desconocimiento generalizado..Hay que estudiar mucho sobre POO (programación orientada a Objetos) para poder entender porque es una mala practica usar variables publicas ya que intervienen muchos conceptos que el maestro Victor comento en el link que pusiste, cuando se entienden esos conceptos y se aplican es donde te darás cuentas que las variables publicas no es una buena practica.

saludos

Antonio Meza

[Luis Maria Guayan]

Hola Miguel, las variables en un formulario, no son las peste porcina, pero ...

En los formularios es recomendable trabajar con Propiedades

Las Variables LOCALES creadas en un método de un formulario, solo tienen alcance en ese método.

Para que un "valor" tenga alcance en todos los métodos de un formulario, lo aconsejable es utilizar Propiedades

Luis María Guayán
Tucumán, Argentina
_______________________________
Comunidad Visual FoxPro en Español
http://comunidadvfp.blogspot.com

[Miguel A.]

Antonio,

Agradezco el tiempo que has dedicado a contestar la cuestión, pero en tu amplia respuesta no veo cómo resolver ninguna de las cuestiones que planteo.

Saludos,

Miguel A.

[Miguel A.]

Gracias Luis,

Entiendo..., y eso resuelve perfectamente la primera cuestión, declarando la variable como una propiedad ya funcionaría desde el Activate del Form, pero cuando hay necesidad de pasar la variable hacia atrás o hacia adelante, ¿cómo sería recomendable hacerlo?.

Saludos,

Miguel A.

[Antonio Meza]

por eso te indique al principio que no contestaba tu pregunta jajajaj

Como te comento el Maestro LuisMa, en vez de crear variables publicas puedes crear propiedades, recuerda que un Formulario es un Objeto y por ello es importante leer a fondo sobre Programación Orientada a Objetos.

Seria mas fácil que pongas la necesidad que tienes para el segundo caso, porque si continuamos con programación orientada a objetos, te contestaría fácilmente que usando Procedimientos y Funciones con el uso de parámetros puedes enviar y retornar valores,

Es decir si tengo un PRG que tiene una Función llamada SUMAR() le envió los 2 valores que quiero sumar como parámetros y le solicito me retorne el valor sumado

? Sumar(10,20)

Func Sumar

     lparameter valorUno as numeric, valorDos as numeric

     local valorSuma as numeric

     valorSuma = valorUno + ValorDos

     return ValorSuma

endfunc

Al enviar parámetros no requiero crear variables publicas, al usar una función puedo obtener un valor devuelto. por eso seria mejor que des un ejemplo real de lo que necesitas.

saludos

Antonio Meza

[Miguel A.]

Si en el Unload del Form se borran todas la variables públicas, tampoco pasa nada grave, no?.

Quiero decir que no se trasladan resultados indeseados a otras partes de la aplicación...

Saludos,

[Luis Maria Guayan]

Si necesitas pasar un valor a un formulario lo haces como:

DO FORM MiFormulario WITH Variable1

Alli en el LOAD del formulario, recoges el parámetro con LPARAMETERS y lo transfieres a una propiedad

LPARAMETERS tuVariable
Thisform.MiPropiedad = tuVariable

En el caso que quieras retornar un valor de un formulario, lo haces en el método UNLOAD con RETURN, previo llamado al formulario con

DO FORM MiFormulario TO Variable2

y en el método UNLOAD, finalizas con la línea

RETURN Thisform.MiPropiedad


No se si aclaro tu duda o estoy haciéndolo fuera del tarro :-D

Luis María Guayán
Tucumán, Argentina
_______________________________
Comunidad Visual FoxPro en Español
http://comunidadvfp.blogspot.com

[Miguel A.]

Sí, eso es lo que preguntaba. Has resuelto mi duda de forma magistral.

Como conclusión creo que si se tiene cuidado de eliminar las variables públicas innecesarias en otros lugares al salir del formulario no hay problema ninguno ¿?

Saludos,

Miguel A.

[Luis Maria Guayan]

El 08/09/2015 a las 16:12, Miguel A. escribió:

Como conclusión creo que si se tiene cuidado de eliminar las variables públicas innecesarias en otros lugares al salir del formulario no hay problema ninguno ¿?

Saludos,

Miguel A.

Lamento no poder contestarte esta inquietud, ya que yo no cuento con experiencia el tema, ya que nunca he utilizado variables públicas en mis aplicaciones ;-)

[Miguel A.]

Si tienes dos formularios que se pueden simultanear y en los que por ejemplo el IDCliente es una variable común a ambos, ¿cómo detectas en uno y en otro formulario el cliente que tiene que abrir en cualquier momento?, si no es con una variable pública cuyo valor vas cambiando, tanto en uno como en otro formulario.

En ese caso yo no he encontrado otra forma de hacerlo, aunque seguro que la hay...

Saludos,

Miguel

[Miguel Canchas]

Que recuerde yo uso solo una o un par a lo mucho….

 

MK

[Antonio Meza]

Por medio de parametros entre formularios puedes hacer eso sin necesidad de variables publicas.

saludos

[Luis Maria Guayan]

Miguel, tengo muchos formularios que reciben datos de identificación de Clientes, Productos, Procesos, etc. para ello lo invoco

DO FORM Clientes WITH lnIdCliente

Que sucede en tu caso si algún proceso cambia el valor de tu variable pública y se invoca el formulario? tu identificación de cliente seria erronea y te llevaría a mostrar/guardar datos incorrectos

Luis María Guayán
Tucumán, Argentina
_______________________________
Comunidad Visual FoxPro en Español
http://comunidadvfp.blogspot.com

[Fidel Charny]

Miguel A:
Puede haber cualquier tipo de problema.
Supongamos que la necesidad de declarar variables públicas deriva de que se necesitan esos valores en distintos puntos de la aplicación.
Ahora bien, si un formulario tiene la responsabilidad de crear las variables públicas y eliminarlas, deberá estar instanciado para que el resto de la aplicación las vea. Si se decide cerrar el formulario que las elimina, los otros formularios se quedarán sin sus variables.

También puede ocurrir:
Form1.load
Public gNumero
gNumero = 100

Procedure PasoPa                && que se lanza desde otro form de la aplicación y no tiene que ver con el Form1
gNumero="G"                       && acá lo pongo como variable "de paso" (PRIVATE)
pNumero="H"
zNumero = pNumero + gNumero

Si esto ocurre, cuando necesite mi variable pública en Form1, saltará un error, supongamos
a = gNumero * 25       && que tratará de ejecutar     a = "G" * 25
Esto, que parece solo un descuido, termina sucediendo en una aplicación con varios miles de líneas.

Como este hay varios ejemplos, entre ellos, la ambigüedad. Si declaras la variable como LOCAL gNumero, ésta tendrá un valor dentro del procedimiento y otro fuera.

Las malas experiencias nos llevan a pensar que debemos prever que la apliacación puede crecer y encontrarse con los problemas mal resueltos en todo lo construido antes.
Y los parches a los que nos puede llevar la desesperación:
a) "Sr. Usuario. No podrá abrir el form Fulano mientras tenga abierto el Form Mengano!".
b) Todos mis formularios son Modales! (un DOS algo sofisticado).
c) Cuando el usuario tiene el formulario "A" abierto y tiene necesidad de abrir uno "B", el B se instancia bien pero... desapareció el Form "A".
PUBLIC oform
DO Form frmA NAME oform linked
DO Form frmB NAME oform linked       && esto cerrará el frmA

Otra sobre variables:
Si en un main.prg (inicio de la aplicación) defino al descuido:
lcVariable = 1
funcionará como una variable pública, a pesar de ser PRIVATE y será vista desde cualquier punto de la aplicación.

Todo esto suponiendo que el programador es uno solo. Si son dos o más programadores que utilizan variables públicas tendrán que hacer un "Protocolo sobre derechos de uso de variables públicas".

[Hugo C.]

Creo que esta respuesta de Fidel es la correcta

"Miguel A:
Puede haber cualquier tipo de problema(s). ... "

Saludos.

[Carlos Miguel FARIAS]

Variables Públicas.

Deben declarse como tales antes de asignarle valor. caso contrario da error.

Una variable pública, una vez declarada, es visible en cualquier otro punto del programa.

Uso: Son para casos muy especiales. Por diseño, solo deben ser "cargadas" en un solo punto del programa, la idea es que fijen datos de caracter general y luego sean usadas en procesos/funciones de orden inferior.

En algunos casos, es admisible que un modulo "llamado" declare una variable pública, pero es algo muy extraño, porque los modulos llamadores u otros de igual nivel, estarían fuertemente acoplados a que un procedimiento de nivel inferior o intermedio haya o no declarado esa variable.

Normalmente, si se necesitan pasar datos "extras" entre distintas partes del programa, se crea una propiedad en _screen (addproperty) y su existencia puede verificarse con pemstatus, de esa manera, no hay tanto acomplamiento.

Otro caso de uso de publicas, es que haya un procedimiento, que carga ciertos datos, siempre se ejecuta primero y los deja públicos.

Lo aconsejable, es minimizar lo más posible el uso de variables públicas y restringirlas a situaciones muy específicas y documentadas.

Por supuesto, cada cual queda en libertad de acoplarse mal y pagar las consecuencias.

Variables privadas.

Las variables privadas en realidad no se declaran.

Una sentencia PRIVATE lo que hace es ocultar a partir de la misma, cualquier variable declarada en módulos superiores que se llamen igual a otras que se asignen a continuación (no en private).

En xbase, una variable declarada en un modulo, es private (salvo public o local expresa) desde ese módulo hacia abajo (o sea desde donde se asigna, será accesible en el procedimiento o función y llamados directa o indirectamente desde alli (salvo local o private en los llamados) no pudiendo declararse luego public.

Cuando no existia el manejo de variables locales, era la forma de encapsular variables, para evitar acoplamiento entre procedimientos y funciones.

Usar variables privadas para pasar datos entre procedimientos y funciones, solo se justifica en estructuras jerárquicas (o sea, se llama a algo que siempre está en una rama inferior al punto de declarar la privada).

El uso de secretari@ privadas puede traer sus problemas si no se tiene en cuenta el ámbito donde se efectúa (salvo single)

Variables locales.

Se crean con LOCAL (con valor falso), toda variable usada en un procedimiento, función método debería ser declarada local, para un mínimo acoplamiento.

Propiedades.

Cuando se trabaja con clases y objetos (que es el caso de los formularios), lo más común es usar la memoria colectiva de la clase y crear propiedades.

Las propiedades públicas (son todas, salvo expreso en contrario) pueden usarse en cuaquier parte del objeto instanciado, puede ser accedido desde fuera de la clase o sus herederas, o sea, son públicas mientras el objeto exista.

Las propiedades protected, solo pueden acceder dentro de la clase y clases heredadas

Las propiedades hidden, solo pueden accederse dentro de la clase (no en sus herederas).

Nunca le vi mucha aplicación al uso de propiedades no públicas, solo se justifica en jerarquias de clases, donde en las clase superior/es, se ejecuta algún método siempre, que prepara algo y las clases que heredan, solo aprovechan los efectos pero no la usan.

Para pasar más de un dato de retorno, tenemos dos opciones básicas.

La opción Fox DOS, que es pasar un arreglo por referencia como parámetro, ese parámetro se carga con todos los valores necesarios y cuando se vuelve al punto de llamada, ese parámetro pasado por referencia, tiene todos los datos que se cargaron en el llamado.

La otra, ya en VFP, es devolver un objeto (empty, rellenado, collection) o alguna propiedad agregada al screen (que hay que ser prolijo).

Mucha veces el Sida se propaga por el uso de public@s sin debidos recaudos.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe si usan publicas inapropiadamente

[Miguel A.]

Gracias a todos por sus respuestas, voy entendiendo la cuestión...

Miguel