Sobre "Read Events"

[HernanCano]

Buenos días, colegas.

Quisiera algo de teoría al respecto de desarrollar applicaciones con
el comando "Read Events".

Tengo algunas dificultades con mi método actual, y ve que casi todo lo
que consulto se basa en "Read Events".

¿Cómo busco los temas aquí que tratan sobre "Read Events"?

Gracias.

-

[HernanCano]

¿Alguien me da una mano?

[Ricardo Martinez]

yo uso Read Events en mi PRG incial / Principal
es decir despues de abrir la base de datos y declarar variables / constantes etc etc
Abro el formulario principal
despues pongo READ EVENTS
y asi empiezas a usar el sistema...
cuando desear cerrar o terminar el sistema, usas Clear Events
y el foco regresa al PRG principal y termina de ejecutar los comandos que pongas despues de Clear Events

por lo general
cerrar la base o tablas, etc etc


--
Saludos. Ricardo Mtz

[Luis Maria Guayan]

Este artículo de PortalFox te puede ayudar:

http://www.portalfox.com/article.php?sid=977

Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________

[Victor Espina]

Hernan. 

Toda aplicacion Windows se basa en algo llamado ciclo de eventos. Un programa principal empieza un ciclo infinito en el que escucha "eventos" y los procesa.  Por ejemplo, cuando tu haces click con tu raton, eso produce un evento que el ciclo de evento de Windows interpreta y lo pasa a la aplicacion que tenga el foco en ese momento.

Las aplicaciones nativas de Windows usan el ciclo de eventos de Windows para manejar sus propios eventos. Sin embargo, en VFP la cosa es distinta. VFP maneja su propio ciclo de eventos, el cual ejecuta en forma paralela al ciclo de eventos de Windows.

Cuando tu abres VFP en modo de diseno, VFP da inicio a su ciclo de eventos y esto te permite ejecutar formas  de VFP desde la ventana de comandos e interactuar con ellas.

Sin embargo, cuando compilas tu aplicacion en un EXE, este EXE es ejecutado por las librerias de runtime de VFP las cuales NO INiCIAN el ciclo de eventos de VFP en forma automatica.  Es por esto que se causa el efecto de que al ejecutar tu aplicacion la misma se cierra automaticamente casi de inmediato.

Justo para esto es el READ EVENTS.  La instruccion READ EVENTS da inicio al ciclo de eventos de VFP y permite que la aplicacion permanezca activa hasta que se detenga la cola de eventos mediante un CLEAR EVENTS.  Esta es la razon por la que un programa puede funconar perfectamente sin un READ EVENTS dentro de la ventana de VFP pero no funcona al compilarla.

El otro involucrado en este tema es la instruccion DOEVENTS. VFP no es capas de procesar los eventos pendientes en su cola de eventos mientras se esta ejecutando algun codigo. Es por esto que VFP utiliza los llamados WaitStates para procesar su cola de eventos. Un wait state es un momento en el que VFP deja de procesar instrucciones y espera por la interaccion del usuario. Esto sucede, por ejemplo, cuando cargamos un form y el mismo se desplega y queda en espera a que el usuario introduzca la informacion y pulse uno de los botones.  Una aplicacion VFP tipica esta repleta de waitstates asi que VFP no tiene problemas en mantenerse al dia con su cola de eventos. y lograr mostrar el cambio visual que estamos generando. Para esto sirve el DOEVENTS.  Al hacer DOEVENTS le permitimos a VFP hacer un pausar y procesar los eventos que esten pendientes en su cola de eventos y en la de Windows, con lo cual logramos que nuestra interfaz visual se actualize correctamente dentro de un proceso intensivo.

Sin embargo, hay que tener en cuenta que no hay que abusar de DOEVENTS. Por ejemplo, poner un DOEVENTS dentro de un proceso que hace muchas iteraciones en muy poco tiempo solo lograra que el proceso tarde muchisimo mas de lo que tardaria sin el DOEVENTS.

Saludos

Victor Espina

[Luis Maria Guayan]

Muy buena y didáctica explicación Victor

Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________

[Arnaldo Toledano]

Excelente Explicación Victor.
Es loable lo tuyo, sobre todo por el tiempo que le dedicas.

Un abrazo


Arnaldo

Sin embargo, hay situaciones en las que nuestro sistema debe realizar procesos que involucran la ejecucion de codigo VFP durante tiempos prolongados, por ejemplo, mientras preparamos los datos para un reporte complejo.  En estos casos, VFP no puede procesar su cola de eventos hasta que no llegue al siguiente waitstate. Si dentro de ese proceso no necesitamos actualizar la plantalla, entonces no hay mucho que hacer. Pero si resulta que el proceso debe actualizar un elemento visual, digamos una barra de progreso, entonces necesitamos hacer tiempo para que VFP pueda actualizar la cola de eventos y 

--
Arnaldo Toledano Tesys Informática Córdoba Argentina

[Jairo Miranda]

READ EVENTS (Comando)

Vea también
CLEAR (Comando) | Diseñador de formularios | DOEVENTS (Comando)

Inicia el procesamiento de eventos.

READ EVENTS
Observaciones
Cuando se ejecuta READ EVENTS, Visual FoxPro inicia el procesamiento de
eventos.

Ejecute CLEAR EVENTS para detener el procesamiento de eventos. Cuando se
ejecuta CLEAR EVENTS, la ejecución del programa continúa en la línea
inmediatamente siguiente a READ EVENTS.

Observe que sólo puede haber un comando READ EVENTS activo a la vez. Si un
comando READ EVENTS está activo, cualquier comando READ EVENTS subsiguiente
no tendrá efecto.

-----Mensaje original-----
De: publice...@googlegroups.com
[mailto:publice...@googlegroups.com] En nombre de HernanCano
Enviado el: Lunes, 09 de Mayo de 2011 23:25
Para: Comunidad de Visual Foxpro en Español
Asunto: [vfp] Re: Sobre "Read Events"