Buenos días
Tengo un campo objeto texto y un formulario para rellenarlo. El caso es que noto mucho retardo a la hora de escribir en el formulario. Cada pulsación de tecla aparece el relojito de windows y tarda mucho en aparecer el texto escrito. Estoy trabajando en red local y ni el campo ni el formulario tienen asociado ningún código.
¿Cual puede ser el problema?
Un saludo
Gonzalo Torre
Has mirado si es problema de los recursos de la máquina en la que estas trabajando…?
Hola Gonzalo.
Por cada pulsación en el campo de Texto se produce una actualización del Interfaz, de las variables locales y de las variables globales. Por lo tanto tendrás que averiguar qué refresco está produciendo ese retardo.
Saludos
Paco Satué
Relacionado:
@seh Paco, y los enlaces virtuales?? También has notado que se recalculan. Es que tengo la impresión que algo afectan en los formularios al igual que en las rejillas.
Hola Manuel.
Sí, tienes razón, los enlaces virtuales los incluyo en la actualización del Interfaz, es decir, si mostramos un control que tenga un enlace virtual éste se estará recalculando cada vez que Velneo ordena un refresco.
Teóricamente en local no debería de ralentizarse por estos motivos, de lo contrario Velneo cogería enseguida fama de lento.
Saludos
Paco Satué
Si en local no se debe notar para nada, pero como se vende tanto el cloud, se debería hacer alguna mejora en ese sentido. Al menos evitar los refrescos automáticos de campos punteros en los edits y dejar que nosotros hagamos un Interfaz->Recalcular.
Si las cosas que nos dan potencia, fichas de extensión, punteros a singular, no podemos usarlos en cloud por que matan el rendimiento de la aplicación…
Hola Manuel.
Totalmente de acuerdo. Seguramente cuando se diseñó la arquitectura de V7 no se estaba pensando en cloud y ni mucho menos en web. Solo hay que ver las pocas herramientas (¡¡ nativas !!), por no decir ninguna, que tenemos para acceso a servicios web. Y lo más evidente es la imposibilidad de disponer de datos offline.
En local o con redes cada vez más rápidas (este es mi caso) las aplicaciones funcionan muy bien.
Los que venimos de SQL sabemos que el diseño siempre es Cliente desconectado por defecto: Conectamos -> Consultamos -> Desconectamos -> Editamos -> Conectamos -> Guardamos.
En Velneo la conexión con el vServer es constante e imperativa. Gracias al protocolo VATP los refrescos son muy rápidos y hay que reconocer que en cloud va bastante bien.
Un singular de plural es una funcionalidad excelente de Velneo. Lo que hay que hacer es no mostrar nunca ese campo en el Interfaz, solo usarlo en código para cálculos intermedios. Así no habrá problemas de retardo, ¡¡o eso creo!!.
Saludos
Paco Satué
Hay casos que si los uso (usaba), por ejemplo:
Son ejemplos relacionados con aplicaciones de gestión y no creo que del otro mundo. Si tuviera ese refresco constante sería perfecto. De ahí que haya que tenido que tirar se funciones y procesos que devuelve el valor para el formulario.
Para el primer ejemplo devuelvo el resultado en json y lo muestro con una tabla en memoria. Al final siempre hay soluciones, pero como tu dices. Además el mismo Velneo dice, programa en la nube y tus aplicaciones serán mejores, sí…pero.
Hola Manuel.
Al final has optado por la solución de cliente desconectado, es decir, haces la consulta trayendo los datos en JSON y trabajas con una tabla en memoria (offline). Realmente es eso lo que ha funcionado siempre en Cliente/Servidor y en aplicaciones puramente web hay que hacerlo así.
Para el caso de mostrar un solo Registro en el formulario se puede almacenar el valor del puntero virtual (por ej. Stock) en una variable local y mostrar ese valor en el formulario. De esta forma, teóricamente, evitamos el problema del refresco.
Para los casos que haya que mostrar registros en una Rejilla, los punteros virtuales descartados.
En su dia probé una técnica que era pasar los valores del puntero virtual a una tabla en memoria que fuera maestro de extensión de la que estamos leyendo desde el servidor. En la rejilla mostramos entonces, junto con los valores de la tabla original, los valores de la tabla de extensión que ya son reales.
Saludos
Paco Satué
Hola foro.
Refloto el hilo porque yo tengo el mismo problema… pero aumentado…
El problema esta en el formulario mas importante de mi aplicacion. Es un pedazo formulario con docenas de campos, varias pestañas, un monton de condiciones de visibilidad (sencillas) y usa bastantes controles con contenido formulas.
En los campos edicion normales (no multilineas) se nota cierta lentitud al teclear, que se hace mucho mas evidente si borras una frase usando Retroceso. Es lento pero se puede usar si no eres un fiera tecleando muy rapido (menos mal que mis usuarios no lo son). Pero extrañamente, si pulso en el campo edicion objeto texto (multilina) se ralentiza muuuucho más.
NO HAY VARIABLES GLOBALES. NO HAY CAMPOS PUNTEROS EXOTICOS. Solo campos normales (eso si, a punta pala), 6 pestañas, muchas expresiones basadas en campos (sencillas, sin cosas raras), y muchas condiciones de visibilidad (todas sencillas, las hago con variables locales booleanas precalculadas o con expresiones sencillas contra campos de la propia tabla).
Bueno el problema es (probado en V 7.16 si slguien lo prueba en v 7.17 se lo agradeceria)…
Si tecleas una simple letra en un campo de edicion alfabetica. SE REFRESCA TODO EL FORMULARIO, PESTAÑAS, FORMULAS. SE REFRESCA TODO DEL TODO. Si te va lento apañatelas para optimizar. Funciona como bien dicen el resto de compañeros. Esto en principio se puede suponer correcto.
En caso del control edicion de objeto TEXTO: el puto formulario SE REFRESCA DOS VECES. NO UNA. SINO DOS. A JODERSE.
¿Sabeis como lo adivine? Os lo cuento por si alguien quiere hacer pruebas… Me encantaria estar equivocado.
Cuando mis usuario me informaron del problema, pues estuve unas cuantas horas haciendo pruebas, por prueba y test, claro. Despues de un buen rato quitando y poniendo cosas, a ver si detectaba que ralentiza mas la edicion del objeto texto, pues llegue a la conclusion de que lo que mas ralentizaba la aplicacion era la llamada a una funcion, que utilizaba en 7 sitios.
La funcion simplemente recibe una fecha, y devuelve la palabra “HOY”, “AYER” o “MAÑANA” comparando con currentDate() si la fecha es uno de esos dias, y sino devuelve fecha formateada como texto. Esta funcion la utilizaba en el Contenido de controles de edicion alfabetico de solo lectura, y como he dicho la llamaba en siete sitios.
Cuando empece a sospechar de ella, ni sabia cuantas veces la llamaba, asi que le puse un mensaje “Me han llamado” dentro de la funcion, para ir contando los mensajes (cutre, eh). Muy bien, asi supe que la utilizaba en 7 puntos…
Bien, ahora el comportamiento extraño de Velneo (otro más, y van…):
Y mas importante aun, ¿alguien confirma/desmiente este “doble refresco” en los controles edicion objeto texto de la v 7.17?
Y no. No lo he reportado a soporte. Deberian saberlo de puta sobra… Que lean el foro si quieren, y que lo arreglen tambien si quieren. Hace mucho que deje de creer en la utilidad de reportar estas cosas a soporte. Me cuesta creer que Velneo no sepa esto.
Un dia de estos me tocara optimizar ese formulario, y tengo unas cuantas ideas al respecto. Cuendo llegue el momento de hacerlo os contare como fue (y seguramente os pida ayuda, je, je). Pero la funcion de fechas me temo que tendre que “eliminarla”.
Si alguien se anima a hacer pruebas, tambien me gustaria confirmar/desmentir que la llamada a funciones en el Contenido de controles ralentizan el refresco de los formularios. Mis pruebas apuntan por ahi.
Repito, todo esto lo probado en v 7.16. La 7.17 no la uso todavia.
Saludos.
Buenos días Victor
Mi escenario es exactamente el mismo. Tengo un superformulario con un separador de formularios con 7 pestañas y muchísimos campos con condiciones de visibilidad y con condiciones de activo. En la mayoría de los casos la condición de activo es simplemente una variable local EDICION. Además en el formulario tengo varias vistas de datos.
Para probar empecé a quitar cosas del formulario y comprobé que el problema estaba en el separador de formularios. Fuí quitando las pestañas de una en una para ver donde estaba el problema y la conclusión que saqué es que no era ninguna en concreto, sino el número de pestañas. Si tengo una pestaña, va bien. Si tengo 2 va algo más lento. Si tengo 3, va peor. Y así hasta que con las 7 va de pena.
Yo uso la versión 7.17
El problema es que, en mi caso, los usuarios SÍ que teclean rápido 
Un saludo
Hola Gonzalo.
¿Tienes algun campo objeto texto? ¿Puedes confirmarme que el problema es mas evidente si tecleas en el objeto texto? Borrando una frase con Retroceso “canta” mogollon.
Saludos.
Hola Víctor
El problema lo han detectado al escribir en un campo objeto texto. En el resto de campos se nota lentitud pero no tan acusada. En el campo objeto texto es muy evidente el retraso.
También tengo varias condiciones de activo y de visibilidad condicionadas a una función que me dice si el usuario activo tiene permiso para hacer/ver eso o no. Puede ser que eso sea lo que ralentiza.
Un saludo
Gonzalo Torre
Más pruebas
Tengo una función PERMISO() a la que le paso una etiqueta y me devuelve si el usuario activo tiene permiso o no. Con esa función controlo las condiciones de visibilidad de varios controles del formulario.
Si quito esas condiciones casi no noto retardo en el control objeto texto. Al menos no le adelanto escribiendo.
Así que el problema está en la llamada a esa función.
Un saludo
Gonzalo Torre
Hola Gonzalo,
No me cabe duda de los problemas del retardo en el refresco y de que haya problemas que no se puedan evitar, pero en el caso que expones creo que tiene una solución muy sencilla.
Ahora tienes una función para controlar los “Permisos()” de visibilidad, y por tanto la función se ejecuta repetidas veces durante la edición, pero dudo mucho que durante la edición del documento, los permisos del usuario vayan a cambiar, por tanto, porque no pruebas a ejecutar la función de Permisos() en el ON_INIT del formulario, y guardas el resultado en variables locales, y usas esas variables para condicionar la visibilidad de los controles, seguro que mejora mucho el rendimiento, y la función se ejecutará solo una vez.
un saludo
José Luis
Hola José Luis
La solución es sencilla. Lo que pasa es que hasta ahora no se me había ocurrido que la lentitud fuera por eso. Yo creía que los tiros iban por el refresco de las vistas de datos.
Las condiciones las tengo sobre todo en botones que llaman a manejadores de eventos, así que lo más fácil es comprobar el permiso al principio del manejador. Si no tengo permiso finalizo y listo.
Un saludo
Gonzalo Torre
Hoa otra vez.
Yo note mucha mejora en el problema cuando quite la funcion de fechas que cite antes…
Parece que se confirma que el problema es el uso de funciones. Que putada. Con lo utiles que son.
Pues habra que quitarlas y recuperar la funcionailidad de otra manera (si se puede, claro).
Yo habia pensado en poner y quitar la visibilidad con comandos de proceso en el evento OnShow de la pestaña (o como se llame en Velneo). Pero me temo que los controles van a ser visibles una decima de segundo.
¿Nadie confirma lo del doble refresco en la 7.17?
Saludos.
Perdon, se me olvido en el ultimo post.
Cuando detecte el problema con la funcion de fechas de marras, lo primero que pense es que la funcion era lenta.
Intente optimizarla de mil maneras, y el resultado era siempre el mismo…
Incluso creo recordar que probe a poner una funcion que simplemente devolviese un valor…
Funcionaba lento…
Creo que el problema no es la funcion concreta que uses… Simplemente es la llamada…
Sobre todo si es verdad que el control edicion de objeto texto refresca dos veces…
Saludos.
Hola No lo he probado, de todas formas ¿has probado el estilo Retardo señal valueChanged ? no se si en tu caso servirá pero puede que sí.
No estoy 100% seguro, las pruebas las hice hara un par de meses. Pero creo recordar que el estilo “Retardo value changed” fue lo primero que probe y no servia de nada en este caso. Encaja si el problema es la llamada a la funcion.
Saludos.