Modificar Ficha 3P no refresca rejilla hasta Acepta

Hola:
Tengo una pantalla que tiene los campos de la cabecera (PEDIDOS) y de detalle (OPERACIONES). Esta última tabla de OPERACIONES alimenta una rejilla no editable que presenta las distintas operaciones que puede el usuario activar. Se activa mediante un “Simple Click” que desencadena la ejecución de un proceso en 3P que se encarga de poner a 1 en campo #BLOQUEO si la operación marcada implica bloquear otras operaciones.
El problema que surge es que tras el Click y recorrer la tabla de OPERACIONES en 3P el cambio de “Modificar Campo” #BLOQUEO no se actualiza en la rejilla. Si sales de la pantalla con Aceptar ya ves los cambios.
Si en lugar de lanzar el proceso en 3P lo lanzas en Primer Plano la rejilla refresca las fichas y se ven los registros #BLOQUEados que el proceso ha marcado.
Todas las tablas están en Disco y en teoría si actualizo algo en 3P debería quedar disponible.
¿Os ha ocurrido algo parecido?
¿Cómo se puede hacer para que cuando modifico algo en 3P recorriendo lista en modo lectura/escritura pueda refrescar la rejilla que estoy modificando.

 Saludos.

 Ricardo Patón

Hola:

 Las soluciones que he visto hasta ahora son:

   1-Lanzar los procesos en 1P.
   2-Lanzar los procesos en 3P y al finalizar y en 1P Recorrer la lista modificando el campo que ya he modificado en 3P para que la aplicación pueda verlo. Verifiqué que los datos se guardaban cuando se lanza en proceso en 3P ya que son accesibles desde otros vClient.
      Sol: 

Crear manejador de objeto ( Bloqueo, Proceso PED_BLO_OPE_INI@vTextil )
Set variable local de objeto ( Bloqueo, ID_PEDIDO, #PEDIDOS.ID )
Set variable local de objeto ( Bloqueo, ID_CUELLO, #PEDIDOS.CU0001.ID )
Set variable local de objeto ( Bloqueo, ID_GUSTO, #PEDIDOS.GUSTO1.ID )
Set variable local de objeto ( Bloqueo, ID_ESTILO, #PEDIDOS.ESTILO.ID )
Set variable local de objeto ( Bloqueo, ID_PUÑO, #PEDIDOS.PU0094.ID )
Set variable local de objeto ( Bloqueo, ID_MANGA, #PEDIDOS.MA0093.ID )
Set variable local de objeto ( Bloqueo, ID_TAPETA, #PEDIDOS.TAPETA.ID )
Set variable local de objeto ( Bloqueo, ID_BOTON, #PEDIDOS.BT0001.ID )
Set variable local de objeto ( Bloqueo, ID_OJAL, #PEDIDOS.OJAL.ID )
Set variable local de objeto ( Bloqueo, ID_BOLSILLO, #PEDIDOS.BO7607.ID )
Set variable local de objeto ( Bloqueo, ID_BAJO, #PEDIDOS.BAJO.ID )
Set variable local de objeto ( Bloqueo, ID_CANESU, #PEDIDOS.CANESU.ID )
Set variable local de objeto ( Bloqueo, ID_ESPALDA, #PEDIDOS.ESPALDA.ID )
Set variable local de objeto ( Bloqueo, ID_INICIAL, #PEDIDOS.IN0068.ID )
Set variable local de objeto ( Bloqueo, ID_HILO, #PEDIDOS.IN0063.ID )
Set variable local de objeto ( Bloqueo, ID_CORONA, #PEDIDOS.IN8099.ID )
Set variable local de objeto ( Bloqueo, ID_BANDERA, #PEDIDOS.BANDERA.ID )
Set variable local de objeto ( Bloqueo, ID_SESION, $ID_SESION@vTextilDat.dat )
Disparar objeto ( Bloqueo, 3º plano: Servidor (síncrono), )
Libre
Cargar lista ( PEDIDOS_OPE_ESP_MEM@vTextilDat, SESION, $ID_SESION@vTextilDat.dat, , , )
Recorrer lista lectura/escritura
If ( #BLOQUEO )
Modificar campo ( BLOQUEO, 1 )

 Como dice Paco Satue el prueba y error.

 Si alguien tiene otra solución y/o explicación a la espera quedo. De momento he implementado la opción 2.

 Saludos.

 Ricardo Patón

Buenas, tu mismo lo has dicho el proceso se realiza correctamente.
Pero hay una cosa que se llama “Refresco terciario”, las modificaciones no te vienen desde que se modifican los datos en el servidor.

NOTA: esperemos que en un futuro se mejore los temas de tcp y se puedan incluso usar “sockets conectados” y podamos avisar a los clientes desde el servidor por ese socket.

Lo que deberías hacer, es una vez lanzado el proceso en 3P recálcular la rejilla, volver a hacer la búsqueda de operaciones.

Hola Manuel:

 El proceso lo lanzo desde la rejilla por lo que Recalcular Rejilla no me deja seleccionar ningún control y el proceso de Refrescar la rejilla lo lanzo desde un manejador de eventos que está situado en un Separador. Es decir, la rejilla está en un separador y por tanto desde la rejilla no tengo acceso a dicho manejador. Se podría lanzar  un click a un botón de refrescar como decía Paco Satue hace unos cuantos post pero son 10 rejillas. De momento lo dejo así.

 Saludos.

 Ricardo Patón

Hola Ricardo.

Yo tengo entendido que cualquier cambio que haga vClient, ya sea en 1P, 2P o 3P, se refleja inmediatamente en el interface del Usuario. Por lo menos así lo he comprobado en mis aplicaciones. El Refresco terciario funciona para cambios que hagan otros vClient en el servidor y es un mecanismo bastante interesante de Velneo, aunque a veces pueda desorientar al Usuario.

Por lo tanto, no veo dónde está el problema. Sigue ejecutando el proceso en 3P y si no se refresca la Rejilla habrá un problema que tendrás que resolver con Soporte. Lo que planteas en la solución 2 es una aberración. Prefiero la solución 1.

El Refresco terciario lo que hace es refrescar la caché de la tabla y a veces tarda unos segundos en producirse. El comando Recalcular lee los datos de la caché, no del servidor, asi que Recalcular no sirve para Refrescar la rejilla con los datos del Servidor. Pero tarde 1 segundo o varios, la rejilla acaba siempre actualizada, de lo contrario hay un fallo en la aplicación.

Saludos
Paco Satué

Hola Paco:

 Lo curioso del asunto es que si quito la "aberración" de la opción 2 que yo decía y accedo al formulario utilizando las opciones de click en la rejilla lanzándose el Formulario de Alta o el Formulario de Modificación indicado en las propiedades de la rejilla funciona perfectamente en 3P. Sin embargo, si accedo desde una Manejador de Eventos del Formulario principal (los típicos botones de Añadir, Modificar, Editar que ponen en las pestañas) no funciona en 3P, solo en 1P. Y no hace refresco terciario (he estado 10 minutos esperando a ver si se refresca sola la rejilla y nada).

 En mi caso en cada pedido lo máximo que voy a tener por rejilla son 8 o 9 registros por lo que de momento la opción 2 es más económica que dejar el proceso de 3P en 1P ya que antes lo tenía en 1P y tardaba mucho. Ahora en 3P lo puedo utilizar incluso en cloud.

 Pasaré el asunto a soporte a ver que dicen.

 Simplemente lo he expuesto en el foro por si a alguien le ocurre que sepa que a alguien más le pasó.

 Si soporte da con ello trasladaré la solución.

 Saludos.

 Ricardo Patón

Hola:
Trasladé la consulta a soporte y en un primer momento me responden:

Es un automatismos de la rejilla el que cuando invocamos directamente un formulario de una rejilla (formulario de alta/formulario de modificación), se refresque su contenido al aceptarlo.

Entiendo que tú lo que quieres hacer es abrir ese mismo formulario de altas de la rejilla desde un manejador de evento del formulario principal. Si esto es así, entonces te recomendaría usar en el manejador de evento directamente el comando de instrucción de proceso interfaz: formulario de alta.

Este comando lo que hace es abrir el formulario de altas de la rejilla del mismo modo que si el usuario lo hiciese directamente.

 Vuelvo a contactar con ellos ya que esa solución no me sirve ya que necesito ejecutar el manejador ya que hago varias cosas en él que de la otra forma me complican toda la interacción del formulario de captura de pedidos y responden:
Cuando ejecutas un proceso en primer plano el refresco se hace de forma inmediata, pero cuando lo ejecutas en tercer plano, el refresco se hace por refresco terciario.

Esto quiere decir que hasta que el cliente no ejecute el hilo de control, no se refrescará la información modificada.

El refresco no se producirá si el formulario no es cuadro de diálogo, pero sí podrás forzar su refresco si al final del manejador de evento del formulario principal recorres las líneas en modo lectura/escritura (sin modificar ningún campo) ya que haciendo esto estarás forzando su lectura en disco.

 Finalmente Paco me indican que utilice la "aberración" para forzar el refresco aunque con el matiz de quitar la instrucción de Modificar Campo, solamente recorrrer la lista en modo lectura/escritura.

 Bueno, ahí queda por si a alguien le ocurre algo parecido algún día.

 Saludos.


 Ricardo Patón

Hola Ricardo.

Bueno, te han dado la solución un poco menos aberrante.
Lo que habría que saber es por qué sucede ésto.
No entiendo la frase:

Esto quiere decir que hasta que el cliente no ejecute el hilo de control, no se refrescará la información modificada.
¿Cuál es el hilo de control en tu diseño? Yo he hecho pruebas con procesos en 3P tanto en formularios modales como en modo Vista y el refresco es inmediato en las rejillas. Quizás tu diseño tenga alguna peculiaridad que evite el refresco terciario.

De todas formas, si así funciona, eso es lo más importante.

Saludos
Paco Satué

Hola Paco:

 Adjunto un PDF (PEDIDOS_PRINCIPAL1.PDF) para que veas el formulario principal en el que pulso el botón AÑADIR que lanza el Manejador de Eventos NUEVA_FICHA (adjunto .PDF) que hace varias cosas antes de presentar el formulario, es decir, lo prepara con unos datos y queda preparado para el caso de Cancelar el Alta. 

 También adjunto un PDF (PEDIDOS_EDITAR1.PDF) para que veas la rejilla que me está dando los problemas al guardar datos en 3P. Cuando hago Click pongo el icono del Visto Bueno (la V) y ejecuto un proceso en 3P que hace cambios en los registros que ves en la rejilla. Cambio el campo #BLOQUEO a 1 y por condición de estilo de la rejilla se pinta en GRIS y queda bloqueado al usuario ya que no podrá hacer click en esos registros grises. 

 La ficha pedido la creo en NUEVA_FICHA y luego utilizo Modificar ficha seleccionada con formulario PEDIDOS_EDITAR1. Puedo cambiar cualquier campo y al pulsar ACEPTAR lógicamente se asientan en disco, incluso lo que modifiqué en la rejilla en 3P, ya que si salgo y entro se aplica la condición de estilo.

 Te adjunto también Manejador de Eventos que lanzo al hacer Click en la rejilla. (CHG_CARGO). 

Saludos.

CHG_CARGO.pdf (24 KB)

NUEVA_FICHA.pdf (18.9 KB)

PEDIDOS_EDITAR1.pdf (199 KB)

PEDIDOS_PRINCIPAL1.pdf (246 KB)

Hola Ricardo.

Le echo un vistazo y te digo algo.

Saludos
Paco Satué

Hola:

 Subo los procesos en 3P para que veas que no hay nada raro, ¡que yo sepa!.

 PED_BLO_OPE_INI es el primero que se lanza y este a su vez lanza PED_BLO_OPE que es el que hace realmente el trabajo.

 Saludos.


 Ricardo Patón

PED_BLO_OPE.pdf (63.2 KB)

PED_BLO_OPE_INI.pdf (20.2 KB)

Hola Ricardo.

Ya te dije que tu diseño tenía alguna peculiaridad que evita el refresco terciario.

En las siguientes líneas está la cuestión:


Cargar lista ( PEDIDOS@vTextilDat, ID, ID_MASTER, , , )
   Seleccionar ficha por posición ( 1 )
      Modificar ficha seleccionada con formulario ( PEDIDOS_EDITAR1@vTextil, B_OK )

La línea “Modificar ficha seleccionada con formulario” crea una transacción que englobará todas las modificaciones que se hagan en el formulario PEDIDOS_EDITAR1, es decir, estás generando un Bloqueo Duro. Esto tiene, entre otras consecuencias, que el Refresco Terciario no funciona.
Seguramente el Refresco terciario NO CONTEMPLA los cambios en el campo #BLOQUEO porque están bloqueados por una transacción y lógicamente hasta que no se confirme dicha transacción no comunica a los vClients que ha habido cambios. Por esta razón hasta que no sales del formulario PEDIDOS_EDITAR1 (se confirma la transacción) no se produce el Refresco de datos.

Puedes plantearte usar PEDIDOS_EDITAR1 con bloqueo Blando y de esta forma poder controlar el tamaño y duración de las Transacciones.

Saludos
Paco Satué

1 me gusta

Hola Paco:

 Gracias por el interés prestado en este caso.

 Efectivamente como lo tengo hecho genera una única transacción y como Modificar ficha seleccionada con formulario crea un Bloqueo Duro no hace el refresco terciario.

 Cambiando en el manejador de eventos NUEVA_FICHA las líneas que mencionas por la siguientes ya hace muchas transacciones y el efecto es el deseado refrescando la rejilla. Tengo que solventar otros problemas menores que me surgen pero de esta forma evitamos el Bloqueo Duro.

Interfaz: Ejecutar manejador de evento ( REFRESCAR, )
Interfaz: Formulario de modificación ( CONTROL, B_OK )

 Saludos.

 Ricardo Patón