Foros | Velneo V7

De momento me parece que lo tendras que solucionar con variables globales, ya que las variables locales no es posible pasarlas de un objeto a otro.

Al menos por el momento, esperemos que pronto sea posible.

Un saludo.

José

Buena overall.

Yo tengo en mis pantallas una variable local para hacer las búsquedas pero despúes la paso a una variable global para todas las búsquedas y no me da ningún problema.

Un saludo.

Jorge Velasco Fernández

jvelasco@theseedsc.com

http://www.theseedsc.com

Soy yo de nuevo,

Pues no acaba de funcionar bien, la variable global que modifico en cada formulario no se refresca correctamente. Me explico.

En cada formulario tengo una variable local (variable alfabética), al perder el foco del campo que la contiene se dispara una conexión a evento que dispara el evento que recalcula el control objeto que contiene la búsqueda. En éste evento, antes de recalcular el control objeto modifico la variable global, para que los datos sean los recién introducidos. Hasta aquí todo correcto. En todos los formularios tengo un proceso ON_INIT que pone, tanto la variable global como la local "vacia".

Cuando lanzo el primer formulario, todo correcto, realizo la búsqueda por trozos de palabra y funciona correctamente. Acto seguido lanzo el mismo formulario, y me presenta los mismos datos que el formulario que ya tengo abierto (y eso que en el proceso ON_INIT refresco las variable, pero no hace caso). Si lanzo de nuevo el mismo formulario el resultado es correcto, me presenta todos los datos.

Esto mismo lo he probado en formularios de datos distintos y el comportamiento es el mismo. Hay un problema de refresco de variables, creo que V7 no las refresca correctamente.

Este comportamiento sobre las variables también se puede apreciar cuando tenemos un botón check que su contenido es una variable global (por poner un ejemplo) le asignamos una conexión a evento que al soltar el ratón nos dispare un evento que recalcule el control objeto. La variable que le pasamos nunca se refresca bien, siempre va a la inversa.

Alguien ha podido apreciar este comportamiento?

Saludos

Overall

Hola Jorge,

Funciona como tu bien dices, pero hay un problema, y es que el objeto control se lanza 2 veces cada vez que iniciamos el formulario. Si se trata de pocos registros, bien, pero el rendimiento se puede ver afectado si la salida es de miles de registros.

Saludos,

Overall

Nosotros utilizamos un módulo exclusivo para resolver esta y otras problemáticas relacionadas con el refresco de controles.
Por un lado la persistencia de las variables locales la almacenamos en tablas en memoria (similar a las variables globales pero con persistencia por usuario/sesión/modulo).
Por otro decidimos que se refresca en función de los valores de las variables locales o de las variables en tablas en memoria.

Tener en cuenta que en la versión actual (v7.2.1) es un problema considerable que las instrucciones de proceso relacionadas con los manejadores de objetos no se puedan utilizar con objetos declarados en el propio formulario (solo se pueden utilizar para crear nuevas instancias, no para manejar las actuales). El conjunto de instrucciones actual no permite realizar fácilmente paso de valores entre objetos contenidos en un formulario. Lo ideal es que mediante estas instrucciones pudiéramos rellenar el valor de las variables locales de los objetos contenidos para luego refrescarlos. Esto permitiría evitar el uso de variables globales para traspaso de gestión de estado.
Otra cuestión similar (derivada de la falta de concreción en estas instrucciones) es el poder gestionar traspaso de variables entre objetos de una multivista...

Menudo tocho me salió...
 

Para mayores detalles revisaros el ejemplo tuiTV que podéis descargar desde nuestra web http://blog.tipesoft.com

Buenas.

No es por desanimar pero creo que las tablas en memoria no estarán para la 7.3

Un saludo.

Jorge Velasco Fernández

jvelasco@theseedsc.com

http://www.theseedsc.com

Buenos dias:

Aunque no tiene que mucho que ver con el tema del hilo... un comentario:

<Idea de bombero retirado>

Las tablas en memoria estar... están... pero siempre están en la memoria del servidor, no en la del cliente. Esto hace que sean, por el momento, prácticamente igual que las tablas en disco.

Con su ubicación actual se me ocurre que se podrían utilizar, marcando en un campo el usuario propietario del registro, para mejorar el rendimiento de ciertos procesos en tercer plano... como estos se ejecutan en el servidor y la tabla está en la memoria del servidor, se reducirían los accesos al disco en estos procesos.

</Idea de bombero retirado>

Un saludo,

Fran

fjpnovo@efeuno.org

http://www.efeuno.org

Overall: Bastante de acuerdo en el tema del rendimiento:

El rendimiento baja considerablemente si realizas demasiadas llamadas a las funciones, para evitar este problema varios criterios a seguir:

Solo se llaman cuando son estrictamente necesarias.

Nunca se utilizan para elementos repetitivos.

Si se pueden utilizar una vez mejor, para ello utilizamos variables locales que contienen el resultado de la llamada (no llamamos dos veces si sabemos que el resultado no a cambiado).

Por último tuiTV muestra la existencia de esta problemática y busca la mejor solución posible. Pocas opciones tenemos si las variables globales son compartidas y las variables locales no se pueden conectar entre objetos relacionados. Sabes de que hablo por lo que no creo que tengas muchas dudas respecto a lo que digo, tal vez tu única duda es si la solución que planteamos es mejorable. Si das en el cómo no dudes en postear... Nosotros no tenemos una solución mejor, por lo que no nos queda otra.´

Por cierto... en nuestro caso el tema de la seguridad también se resuelve de forma similar en PaaSOS - Nueva funcionalidad de PaaSOS – tuiSecurity ACL’s

Fran... me perdí... Razón no te falta: en el server van bastante lentas, lógico la petición es de ida y vuelta. Si planteas otra solución desarrolla un poco, estoy un pelín espeso y no entiendo tu solución.