Re: Problemas Con Valuebox...
Citar:
Pero la variable publica es común usarla ya que es global al formulario, modulo.
No exactamente. La variable publica es común a la aplicación entera (técnicamente a toda clase que tenga una referencia a la clase o módulo donde se declara, que otro tema es que los símbolos de los formularios sean públicos o no). Si deseas una variable visible al módulo o clase utiliza una PRIVATE.
Citar:
Es reconocida por todos los procedimientos o funciones que se encuentre esta.
El que sea reconocida por todos los procedimientos o funciones es, precisamente, el problema.
Sin entrar en la POO, el tema del encapsulamiento ya era propio de la programación estructurada. Una variable pública puede ser modificada desde cualquier sitio, y por tanto no puede ser controlada con precisión. Un ejemplo: Imagínate que almacenas la clave del individuo actual en tu aplicación de clientes en una variable pública. Perfecto, así sé en cualquier sitio "de quien estamos hablando" y no tengo que preocuparme de nada más. Sin embargo eso sólo funciona si en todos los "vaivenes" del flujo de la aplicación (funciones que llaman a funciones que a su vez llaman a otras funciones y luego vuelta atrás) ninguna toca el contenido de esa variable... si es que no hay que tocarlo, claro.
Cuando haces la versión Alfa de tu aplicación todo está muy claro en tu cabeza y todo funciona guay. Cuando 6 meses -o dos años- después tienes que añadir una funcionalidad o modificar otra en la aplicación... ya no está tan claro. ¿BuscaNuevoTio(dni as string) as boolean, cambiaba la variable global? ¿y CancelaCambios(res as result) as result) ¿Pregunta si cambioDni(cDni as string) llegaba a cambiarla si se pulsaba cancel?, etc. etc.
Y eso con variables string o integer, que cuando hablamos de variables como result, que son "tocadas" por las clases internas de
gambas, muchas veces sin pretenderlo nosotros, ya ni te cuento. ¿Un .update fallido me cambia el contenido de mi result público?, un movenext para ver si era el último o no me guarda los cambios no grabados al hacer moveprevious?...
Creo que me explico. Variables públicas las mínimas.
Y que conste que no soy ningún pureta del asunto, que en mis aplicaciones hay variables públicas. Que muchas veces las creo "temporalmente hasta que haga una clase" y así se quedan per secula seculorum... pero es que nadie es perfecto, oiga. Aunque conviene distinguir las buenas y malas prácticas...
Citar:
Con locales, aumentarías el numero de variables.Claro que liberaría la memoria
al salir del procedimiento o función.
Eso es cierto... casi siempre. Con la memoria que tienen las máquinas hoy día no es muy relevante el número de variables (salvo que te lances a crearlas en bucles y cosas así), pero no siempre se destruyen al finalizar la función que las crea. No olvides las que antes llamábamos (no sé si ahora se siguen llamando así) variables locales separadas, que si no controlas también pueden dar problemas...