[Sintaxis] Método "ThruEvents"

[Kuk]

Amigos, he visto que los Forms del Power 3 no tienen método "ThruEvents" (o lo que es lomismo en Borland/Embarcadero el método "Update").

Cómo solucionáis este tema en los bucles?

Si no hay solución, habrá que acudir a WinAPI "InvalidateRect" + "UpdateWindow" o algo así (nunca lo he necesitado, no sé cómo va exactamente)...

Añadido despues de 1 hora 12 minutos
He encontrado la solución! El equivalente el "ThruEvents" serían 2 llamadas a WinAPI:

         MOVE "InvalidateRect" TO FUNC
         
         CALL FUNC WITH STDCALL USING BY VALUE hWnd
                                      BY VALUE 0
                                      BY VALUE 1
         
         MOVE "UpdateWindow" TO FUNC
         
         CALL FUNC WITH STDCALL USING BY VALUE hWnd

[Rapinto]

Kuk,

Só queria deixar a minha opinião sobre este assunto.

A minha ideia sobre "ThruEvents" ou "Doevents" em VB6, é que a rotina que está a ser executada, deixa de ser executada e todos os eventos pendentes são processados. Em seguida retorna ao ponto onde estava.
Um exemplo concreto:

Estás a executar o código no evento "Click" dum botão.

MOVE A TO B.
COMPUTE A = B + C
INVOKE POW-SELF "THRUEVENTS"
 
IF A NOT = ZERO    .....

Quando é executado o THRUEVENTS, a instrução IF a seguir não é logo executada.
Se o operador tivesse entretanto feito um click numa listview, esse código começava a ser executado por causa do THRUEVENTS e só depois regressava á instrução IF a seguir.

A opinião geral de muitos programadores é que se deve evitar o uso do THRUEVENTS, pois deixamos de ter um controlo rigoroso do que se está a executar.

Se tiveres o FujitsuCobol ver. 9, podes testar isto que eu digo.
Por outro lado, as instruções de CALL que estás a utilizar, parecem-me mais a instrução do COBOL9: INVOKE POW-SELF "REFRESH" (mas posso estar enganado).

Citado de Microsoft MSDN (DoEvents em VB6 = ThruEvents em COBOL):

❞ DoEvents passes control to the operating system. Control is returned after the operating system has finished processing the events in its queue and all keys in the SendKeys queue have been sent. DoEvents is most useful for simple things like allowing a user to cancel a process after it has started, for example a search for a file. For long-running processes, yielding the processor is better accomplished by using a Timer or delegating the task to an ActiveX EXE component.. In the latter case, the task can continue completely independent of your application, and the operating system takes case of multitasking and time slicing. Caution Any time you temporarily yield the processor within an event procedure, make sure the procedure is not executed again from a different part of your code before the first call returns; this could cause unpredictable results. In addition, do not use DoEvents if other applications could possibly interact with your procedure in unforeseen ways during the time you have yielded control.

Espero que esta pequena explicação possa ajudar alguém aqui no foro.

Un saludo, Rui Pinto

[Kuk]

Rapinto, gracias por esta info. Yo lo sabía, pero uso bastante el ThruEvents en los bucles, donde actualizo un ProgressBar o casos similares. El método Refresh no hace nada (al menos yo siempre que lo he usado no ha hecho nada)...

Normalmente uso el ThruEvents antes del END-PERFORM.

[Josber]

❞ Rapinto, gracias por esta info. Yo lo sabía, pero uso bastante el ThruEvents en los bucles, donde actualizo un ProgressBar o casos similares. El método Refresh no hace nada (al menos yo siempre que lo he usado no ha hecho nada)... Normalmente uso el ThruEvents antes del END-PERFORM.

¿ Y no te ralentiza el programa, ni te hace "pirulas" raras ?, porque lo que haces es forzar a que todos los subprocesos pendientes, se ejecuten, ¿no?

Un saludo.-

[Kuk]

❞ ¿ Y no te ralentiza el programa, ni te hace "pirulas" raras ?, porque lo que haces es forzar a que todos los subprocesos pendientes, se ejecuten, ¿no?

Sií que ralentiza un poco, pero no mucho (depende del tamaño de los datos). Pero esto se puede controlar, si hay muchos datos, haces ThruEvents cada x registros (como lo que hacemos con COMMIT en BBDD).

Si lo usas bien, no da ningún problema. Mira, estoy en un tratamiento "masivo" de datos con un bucle, lo que hago es dehabilitar el Form (propiedad "Enabled") y para mejor viasualización - puntero de espera. De esta manera, el usuario no puede lanzar subprocesos agenos. Luego, dentro del bucle, al final de cada iteración meto el ThruEvents. Esto lo que hace es ejecutar los procesos pendientes, pero únicos que hay son lo que yo manejo (el ProgressBar, un CmStatic etc.). De esta manera, no me ejecuta la siguiente iteración del bucle hasta que no redibuje la pantalla con los nuevos datos.

El unico proceso "incontrolable" que queda es el foco de la ventana en sí, pero se control por Windows. Así que si WIndows ha ordenado enfocar o desenfocar la ventana, es justo en el ThruEvents donde lo veríamos "bien" (a tiempo).