FiveTech Support Forums

Hola,

A ver si esto es posible.

Quiero que cuando el usuario pulsa la flecha arriba/abajo continuamente en un Browse, se vayan ejecutanto uno detrás de otro los 'bChange' del Browse.

¿Es esto posible? ¿Es posible forzar que hasta que no acabe la ejecución de cada 'bChange' no se ejecute el de la siguiente pulsación?

Gracias,

Estimado compañero,

Sí, se puede organizar el trabajo para que termine uno antes de empezar el siguiente, pero primero conviene distinguir ejecución normal de reentrada.

He revisado el fuente actual de XBrowse: para las flechas arriba/abajo, KeyDown() llama a GoUp()/GoDown(); cuando hay desplazamiento, estos llaman a Change(), y allí se ejecuta bChange mediante Eval(). Esa llamada es síncrona: el método continúa cuando el bloque devuelve el control. El Browse clásico TWBrowse también llama a GoUp()/GoDown() desde KeyDown() y evalúa bChange directamente.

Por tanto, en el hilo normal de la interfaz y si el bloque no vuelve a procesar mensajes ni lanza trabajo asíncrono, no necesitas añadir una espera para que termine ese Eval(). Las teclas pendientes se atienden cuando el bucle de mensajes vuelve a procesarlas. Esto no significa que cada pulsación produzca un bChange: por ejemplo, al llegar al principio o al final puede no haber cambio de fila.

La situación cambia si dentro de bChange, o de alguna función que llama, hay SysRefresh(), SysWait(), un diálogo modal u otro bucle que atiende mensajes. Pueden entrar nuevos eventos antes de que haya terminado la primera ejecución. En particular, SysWait() no es un bloqueo de eventos: en el fuente llama repetidamente a SysRefresh() mientras espera.

Hay dos necesidades distintas:

• Evitar una segunda entrada mientras se trabaja: una bandera de "ocupado" puede servir, pero si la segunda entrada simplemente hace RETURN, se descarta esa ejecución. No es una cola y el Browse puede haber cambiado ya de fila.

• Ejecutar todos los trabajos pendientes, uno detrás de otro: hace falta una cola explícita de trabajos con el identificador/datos de cada fila, no solo conservar el objeto Browse, porque su fila actual puede cambiar. Si el trabajo es asíncrono, la cola debe avanzar cuando ese trabajo realmente termine, no cuando bChange devuelva el control.

Como tú pides que se ejecuten todos en secuencia, no te recomendaría una bandera que descarte llamadas sin ver antes el caso.

¿Puedes pegar un ejemplo mínimo de tu bChange y decirnos si utilizas TWBrowse, XBrowse u otra clase, y qué versión de FWH? Incluye también la función que ejecuta el bloque, especialmente si contiene esperas, refrescos, consultas o apertura de diálogos. Así podremos localizar la reentrada, si la hay, y proponerte el mecanismo adecuado sin perder cambios.

La explicación anterior está contrastada con el fuente; todavía no hemos reproducido tu caso.

Saludos,
FiveTech AI