Estoy optimizando la carga de un formulario que en cloud tardaba entre más de 5 seg.
Es un fomulario con muchos subformularios. Todos están optimizados con las búsquedas en 3º plano… Usando el monitor de vClient, lo único que hacía era leer unas variables en disco para mostrar una información u otra. He cambiado las condiciones de visibilidad poniendo en lugar de variables campos enlazados y ha mejorado bastante.
Ahora las preguntas, ¿Hay alguna forma de condicionar la visibilidad de las columnas de una rejilla que no sea con variables?, ya que los campos si que puedo condicionar su visiblidad a un valor de una tabla enlazada, pero las columnas de una rejilla no.
Para probar, he quitado todas las rejillas que tenían columnas condicionadas y se gana un poco más, pero aun así sigue tardando un par de segundos. ¿Alguna idea más?
Imagino que, además de que las búsquedas estén en 3º plano, tendrás también optimizado el tema de que las rejillas de los subformularios no se carguen hasta que se muestren. No tiene pinta de que sea así, pues si no, no te tardaría tanto tiempo.
Si estás trabajando con 7.22.1, tienes una opción en los controles de vista de datos llamada “Modo de carga”, que debes indicar como “Al mostrar la primera vez”.
Gracias por la respuesta. Estoy en la versión 7.22.1 y todos los subformularios con rejilla tienen el modo de carga “Siempre que se muestra”. Los que llevan búsqueda, la tienen realizada en 3P (los que no es cargar un histórico)
Si que es cierto que hay muchos subformularios, pero tampoco me cuadra. Tras quitar las variables globales, tarda entre 1 y 2 segundos y con el monitor de vClient no veo ninguna transacción.
As comprobado los mensajes del vAdmin??, si tienes algún problema con un índice de una tabla que esteas utilizando el resultado puede ser ese, una carga muy lenta.
Prueba también a poner un mensaje en los procesos de carga de los formularios para comprobar cuales se están disparando en la carga inicial, ese modo de carga, por las pruebas que he realizado, puede realizar cargas que no esperamos. Por ejemplo, si utilizas el control por JavaScript para que se habrá un formulario solo una vez, este modo de carga provoca la recarga de todos los formularios que tengamos abiertos y lógicamente tengan este tipo de carga establecido.
El problema surge por cómo tenemos que leer los formularios abiertos desde JavaScript. El control de formulario abierto y este modo de carga son a día de hoy incompatibles, vamos si quieres que tu aplicación funcione a una velocidad adecuada.
Por curiosidad aunque supongo lo has tenido en cuenta, no habrás puesto alguna fórmula en las rejillas, ni colores, que retarden la carga, si metes alguna formula que sea de contenido inicial, no de fórmula o incluso creas un proceso que que un campo numerico coja el valor del campo formula y muestras el campo numerico
He realizado la prueba de poner un mensaje en el post-ini de cada formulario que se usa en el artículo y al abrir el formulario de artículos, que contiene 17 formularios entre sub-formularios y sub-sub-formularios muestra los 17 mensajes.
He probado a poner dos separadores con una condición de visibilidad y un botón de información extendida (uno con 2-3 sub y el otro con todos), pero en ese caso carga todos los subformularios de ambos separadores.
Lo que no hace es cargar las listas (comprobado también por mensajes).
En local funciona bien, pero en cloud le cuesta un par de segundos.
He probado a poner dos separadores con una condición de visibilidad y un botón de información extendida (uno con 2-3 sub y el otro con todos), pero en ese caso carga todos los subformularios de ambos separadores.
Eso es muy cachondo, me pasó también.
Prueba a en lugar de crear 2 separadores con condiciones para el tema de informacion básica/exendida a:
1 control pila de formularios
Contiene sólo el formulario de información básica
Botón de Más datos
El botón quita la información básica y la sustituye por el formulario que contiene todas las fichas en un separador
var formulario = theRoot.dataView();
var separador = formulario.control( "PILA_PRIN" );
// Quita los formularios
var posicionInsercionTab = separador.findForm("ERP_app/ART_M_GEN");
if ( posicionInsercionTab != -1 )
{
separador.removeForm( posicionInsercionTab );
};
// Inserta más datos
var numSubForm_Mas = separador.findForm("ERP_app/ART_M_MAS_DAT");
if ( numSubForm_Mas = -1 )
{
separador.insertForm( 0, "vERP_NRK_app/ART_M_MAS_DAT");
};
Retomo este correo ya que me pasa exactamente lo mismo.
El formulario con 10 subformularios incluidos en un separador de subformularios me carga en 2/3 segundos.
Todas las búsquedas las tengo optimizadas en tercer plano y unicamente se disparan si la vista está activa.
Cita
He realizado la prueba de poner un mensaje en el post-ini de cada formulario que se usa en el artículo y al abrir el formulario de artículos, que contiene 17 formularios entre sub-formularios y sub-sub-formularios muestra los 17 mensajes.
Cita
Lo que no hace es cargar las listas (comprobado también por mensajes).
En local funciona bien, pero en cloud le cuesta un par de segundos.
Ambos puntos se cumplen en mis pruebas. He incluso he eliminado tanto la conexión de evento como el manejador POS_INI ya que no le daba ningún uso en concreto.
Pruebo a quitar el objeto del separador de formularios y la carga es instantánea.
Mi idea es seguir manejando dicho objeto y no cambiarlo por la solución que planteó Sergio, ¿cómo habeis eliminado ese retardo en la carga del formulario?
Pruebo a quitar el objeto del separador de formularios y la carga es instantánea.
Entonces es un caso perfecto para usar la extensión del Monitor de VClient.
Compara los dos escenarios, con o sin separador, y quizás te dé alguna pista de lo que está ralentizando la carga del formulario.
Había usado el Monitor de VClient para identificar todas las llamadas a plurales y lo he optimizado hasta dónde he podido averiguar qué significa cada punto.
Añado al hilo una captura en la que se ve la diferencia al abrir el mismo formulario con y sin subformularios.
Hay un fallo “imperdonable” en la extensión con la columna de comandos porque no muestra el texto completo.
Parece que se “Ejecuta un proceso sin origen en el 3P” contra el enganche 2-1388-5424-4738.
Puedes mirar por ahí.
De todas formas, puede que ese sea el timing normal de Velneo con tanto subformulario. Prueba a ir quitando uno a uno los subformularios hasta que obtengas un valor adecuado.
El proceso en 3P se trataba del primer subformulario del objeto, por lo que ahí no estaba el problema ( no caí en que ese proceso era la primera carga de plurales ).
Y luego fui optimizando los el número de subformularios de manera que lo reduje en 3 objetos menos, por lo que la carga es instantanea en pantalla.
