Sobre rendimiento y uso de procesador por app VFP

[HernanCano]

Hola, chicos. Buenos días.

Hoy he decidido consultarles acerca de un problema que tengo en mis aplicaciones: el ejecutable se lleva todo procesador disminuyendo la eficiencia en el sistema.

Mi aplicación tiene la siguiente MAIN.PRG (lo reduje para esta pregunta):

* Programa principal
* MAIN.prg
clea all
set dele on
clear
M.lSalir = .f.
do while .t.
   wait clear
   clear program
   do MyMenu
   if M.lSalir
      on shutdown quit
      close databases
      quit
   endif
enddo
**

Estoy notando que si minimizo mi app y dejo abierto el administrador de tareas, un instante después de minimizar, el uso de la CPU se coloca en el 100% y así se queda; evidentemente noto degradación de rendimiento en el sistema.

Me gustaría saber qué ha descubierto alguien al respecto.

HERNAN CANO M
Analista de Sistemas - Programador

[Luis Maria Guayan]

Te aconsejo que mires la ayuda de READ EVENTS y lo utilices en tu programa principal, quitando el bucle DO WHILE que utilizas. Te paso el enlace a un artículo que muestra una estructura tipo para un programa principal.

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
_________________________

[Hernan Cano]

Bien, Luis. Te agradezco que me contestes.

Voy a avanzar rápido.

Mi duda es: ¿Cómo hago para compatibilizar mi administrador de errores ( RETRY para Reintenter / RETURN TO MASTER para Cancelar ) con este comando Read Events)?

Chao.

[Luis Maria Guayan]

Veo que utilizas estructuras antiguas ¿Eres un desarrollador Seniors o Juniors en VFP?

Para tus errores utiliza la estructura de errores TRY ... CACHT ... FINALLY

Luis María Guayán
Tucumán, Argentina
_________________________

http://www.PortalFox.com
Nada corre como un zorro
_________________________

[HernanCano]

Bueno, Luis. Si bien ya no me considero junior, admito que no llego a tu nivel de senior.

Verificaré las ventajas y manejo de la estructura TRY/CATCH.

Gracias. Hasta pronto.

[Fernando D. Bozzo]

Hola Hernán:

Tu problema es lógico, ya que estás ejecutando un bucle DO WHILE que no deja de ejecutarse nunca. Como te dice Luis María, READ EVENTS es para eso, aunque no es necesario que reemplaces tu manejo de errores, que seguirá funcionando perfectamente.

Lo único que tenés que tener en cuenta es que para terminar el READ EVENTS vas a necesitar el CLEAR EVENTS correspondiente, por ejemplo en la rutina de ON SHUTDOWN

Te recomiendo que te hagas un programita de pruebas para probarlo, y tené en cuenta que CLEAR EVENTS hace que se sigan ejecutando los comandos que haya a continuación del READ EVENTS


Saludos.-

[Carlos Miguel FARIAS]

Ese algoritmo de do while se usaba antes de que en el Fox p/DOS se implementara el READ fundacional (o como quieran traducirlo).

El READ EVENT es un bucle también pero controlado por el S.O. o sea que está esperando alguna acción de la interfaz de usuario (controles, formularios, etc.) que se produzca a través de algún dispositivo (mouse, teclado, discos, etc.) y por lo tanto, mientras eso no se produzca, el S.O. toma el control para otras actividades y no le computa tiempo de proceso a la APP Fox.

Con el DO WHILE, el control lo sigue manteniendo la aplicación VFP y todo el tiempo del ciclo se lo asigna el SO al APP.

Tu código, podría reemplazarte más o menos como sigue a continuación:

SET TALK OFF && Amerita mejor rutina de apertura

CLEAR ALL

ON SHUTDOWN DO QuiereSalir()

DO YourMenu

READ EVENTS

CLOSE DATABASES && Amerita mejor rutina de cierre

QUIT

PROCEDURE QuiereSalir()

   * Pregunta si quieres salir Botones Si y No + Signo ?

   IF MESSAGEBOX("Desea Salir de Aplicación", 36, "Nombre aplicación")==6

      CLEAR EVENTS

   ENDIF

ENDPROC

En tu opción de menú donde fijabas tu variable global M.lSalir en Verdadero, colocas el comando CLEAR EVENTS, y no deberías tocar el resto de tu lógica. O tus formularios tienen READs?

Saludos: Miguel, La Pampa (RA)

[HernanCano]

Sí, Fernando. Es conveniente la prueba que me propones.  Así lo haré

[HernanCano]

Miguel:
Así es como veo el uso de READ EVENTS por todas partes.
Mi inconveniente con este código es que mi manejador de errores tiene sólo dos opciones: una de ellas es para Reintentar y ejecuta RETRY; y la otra es para Cancelar y ejecuta CLOSE DATABASES y RETURN TO MASTER, pero este RETURN me llevaría al MAIN.PRG a la siguiente línea del Return to Master, lo cual sólo serviría para abandonar el programa (Quit), pero lo que deseo es que regrese al menú. Por éso es que tengo el "ciclo infinito".

A este escenario llegué por mi propia deducción en mis inicios, y sí, lo sigo usando; es sólo que acabo de ver el consumo de procesador y quería optimizar.

>>> O tus formularios tienen READs?

Los formularios no, claro que no.

Les recibo sus recomendaciones porque sé del altruismo del foro. Las analizaré.

Muchas gracias.

[Carlos Miguel FARIAS]

No entendí, usas READ EVENTS por todas partes?

Bueno, no importa, cada cual resuelve la lógica como mejor la entiende.

Simplemente, lo que estamos recomendando es que el bucle do while, te va a producir consumo de proceso continuamente.

Además, aparentemente, estás cerrando todo y volviendo a recrear el menú en cada ciclo, eso también consume recursos.

En realidad, el menú, una vez creado, no debería ser reconstruido, porque siempre el menú es disparador de eventos (no hay ciclo de lectura allí) salvo que se use algunas de las variantes de menú de los xbase originales.

Saludos: Miguel, La Pampa (RA)

[HernanCano]

Sí, Fernando.
Las ayudas de READ EVENTS dicen que sirve para iniciar el proceso de eventos (nada más).

He notado que si en vez de  " wait window [] nowait ", utilizo:

wait window "" timeout .005

el consumo de procesador ya no alcanza el máximo.

Espero que esta info pueda serles útil.

------------------------------------------------------------------------------------------------------------------

El lunes, 9 de diciembre de 2013 02:16:15 UTC-5, Fernando D. Bozzo escribió:

[Hernan Cano]

>>> No entendí, usas READ EVENTS por todas partes?

No, lee lo que digo:

"Así es como veo el uso de READ EVENTS por todas partes".

Así es como veo que se recomienda el uso de READ EVENTS en cualq documento que veo.

>>> ...el bucle do while, te va a producir consumo de proceso continuamente...

Un ciclo infinito sí, pero es que hay un menú en el que se frena todo para esperar la respu del usuario. Por lo tanto lo de "consumo de proceso continuamente" no lo capto.

[Luis Maria Guayan]

Hernan, veo que estás cerrado en tu DO WHILE y es difícil ayudarte así :-(

Quieres cambiar solo un WAIT WINDOWS y debes cambiar la estructura de tu programa principal

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

[Fernando D. Bozzo]

Hernán:

Arreglar eso con un wait window es como arreglar un motor con alambre, pero bueno, supongo que cada uno decide si quiere aprender a hacer las cosas bien o a arreglar con parches y trucos.


Saludos.-

[Jorge L. Florez C.]

Hernan, en que parte de tu programa llamas al read events?, cuantas veces llamas al read events?.... no necesariamente el poner una estructura como tu lo has definido (do while... enddo) hace lento el sistema o aumenta el consumo de CPU es mas, yo lo tengo implementado de esa forma, un do while.. enddo y no me consume la CPU como a tu indicas.

Saludos

Jorge Florez

Lima - Perú

[HernanCano]

Jorge:
Si observas mi post inicial, notarás que no uso READ EVENTS:

* Programa principal
* MAIN.prg
clea all
set dele on
clear
M.lSalir = .f.
do while .t.
   wait clear
   clear program
   do MyMenu
   if M.lSalir
      on shutdown quit
      close databases
      quit
   endif
enddo
**

Eso es lo que me están indicando mis compañeros: que debo cambiar mi estilo de programación a sí usar READ EVENTS.
Mi inconveniente es que con este esquema el uso del procesador se lo come mi app VFP (se sube al 100% cuando la minimizo).
Yo les replico que si uso lo sgte:

* Programa principal
* MAIN.prg
clea all
set dele on
clear
M.lSalir = .f.
do while .t.
   wait clear

       wait window "" timeout .005

   clear program
   do MyMenu
   if M.lSalir
      on shutdown quit
      close databases
      quit
   endif
enddo
**

el consumo de CPU se normaliza y no se pone en el 100% cuando lo minimice.
No me digas que te parece extraño que por un DO WHILE...ENDDO el consumo suba. Yo no lo digo, sino que mis colegas me dicen que debo cambiar mi estilo del DO WHILE...ENDDO al de READ EVENTS.

[Carlos Miguel FARIAS]

Hernan, si no quieres cambiar el bucle do while, no lo cambies, pero el wait window timeout, lo que hace es liberar en cada vuelta 5 milésimas de control al procesador, por eso te indica que consume menos la app.

Pero no es una solución definitiva.

El read events, libera todo el idle de tu aplicación al procesador, y por ende, el consumo será mucho menor.

Una aplicación VFP, necesita un solo READ EVENT.

La ubicación natural del READ EVENT, es inmediatamente después de generado el menú principal.

Y generalmente, una opción del menú dispara el CLEAR EVENT.

El READ EVENT, reemplaza al READ fundacional, que no tenía un formulario asociado (solo el menu principal). Luego cada formulario tenía su propio READ, con posibilidad de hasta 6 READ anidados (contando el fundacional).

De ahi surge el concepto (necesidad) del formset, ya que el formset se manejaba con un solo READ.

Hasta hay comandos en vfp (no los he usado), pero que permiten pasar el control al S.O. DOEVENTS o algo así.

Saludos: Miguel, La Pampa (RA)

[HernanCano]

Ok.
Aún espero me indiques cómo manejo el RETURN TO MASTER para cuando necesite CANCELR en un evento de error, bajo la filosofía de READ EVENTS.
Voy a implementar algo que estoy pensando sobre ésto y continuamos.....

[Carlos Miguel FARIAS]

El RETURN TO MASTER es equivalente a un GOTO etiqueta de otros lenguajes. También es una solución que no aconsejo.

En VFP hay tres formas de interceptar errores

Una genérica u ON ERROR DO ManejaErrores WITH bla bla

Otra por objeto con el método ERROR (los formularios son objetos)

y finalmente con TRY CATCH

De una rutina de error puedes salir con return (vuelve a la sentencia siguiente a donde se produjo el error) o con retry (vuelve a la sentencia donde se produjo el error.

Sugiero este material para ver el tema de manejo de errores.

http://doughennig.com/papers/..%5CPub%5Cerrorh.pdf

Hay que tener en cuenta que VFP, por compatibilidad descendente (código legacy) mantuvo muchos comandos, solo a los efectos de que programas que ya funcionaban como se necesitaba, siguieran haciéndolo.

En tu caso, si el programa funciona, déjalo como está, ahora si quieres solucionar tu problema de uso de CPU, deberás refactorizarlo para instrumentar las soluciones que se te han indicado.

Saludos: Miguel, La Pampa (RA)

[HernanCano]

>>> De una rutina de error puedes salir con RETURN  (vuelve a la sentencia siguiente a donde se produjo el error) o con.......

Miguel:
¿Consideras adecuado que ante una excepción el sistema devuelva el control del flujo del programa a la instruccion sgte a donde se produjo el error?
Disculpa, pero yo veo una falla de integridad de información ahí!!! Si se necesita grabar un registro en un DBF o en un archivo de datos de un motor externo, o si debe escribir en la impresora un dato, o di necesita reportar algo al usuario, y no lo hace por el error.... entonces ¿puede seguir campantemente a la línea sgte?

[Martin Peveri]

Hernan una pregunta, cual es el problema de cambiar el bucle por el read events?. Yo siempre utilizo este último.

Saludos 

[HernanCano]

Martin:

>>> Hernan una pregunta, cual es el problema de cambiar el bucle por el READ EVENTS?

Que entonces necesitaría saber cómo manejo el RETURN TO MASTER para cuando necesite CANCELAR en un evento de error, bajo la filosofía de READ EVENTS.

[Carlos Miguel FARIAS]

Cuando una rutina me captura un ON ERROR, es porque es una situación muy rara, pero que en principio debería poder recuperar.

En todos los casos, el error lo registro, para que me queden datos de donde se produjo el error, pila llamadas y un monton de cosas mas (no puedo pretender que el usuario tome nota).

Si la rutina subsana el problema que produce el error, reintento con un RETRY, si no, modifico una global que me informa de que ha acontecido un error en una instrucción y regreso con un RETURN luego de la instrucción que produjo el error.

Los errores, normalmente, deben producirse ante situaciones que no pudiste prever una falla (programación defensiva).

Y luego, en todas las situaciones que correspondan, verifico la variable global de error.

Muchos de los errores se producen por no hacer un buen circuito de acceso.

Por ejemplo. En Fox DOS tengo centralizada la apertura de tablas, donde verifico cierre anterior del sistema y hago los recuperos de indices que sean necesarios.

Todos los accesos a datos deben estar "envueltos" en código que controle que estoy en el área que corresponde, que los indices que necesito estén abiertos y dale que va.

Con objetos, en lugar de procedimientos, genéricos, transferí la lógica a metodos (error) y luego te manejas con try catch.

Creo que el try catch es la mejor solución de manejo de errores.

No entiendo como un return to master te permite solucionar el problema, que causo el error.

Generalmente, en una rutina de errores, si no podes solucionar el problema, lo mejor es que el sistema cancele y el operador avise del problema, que seguir intentando hacer, porque lo más probable es que siga agrabando el problema y cada vez sea más irreparable.

En fin, si funciona, dejalo, si lo querés menos consumista, pasate el READ EVENTS.

Saludos: Miguel

[HernanCano]

Sí, Miguel.

>>>  No entiendo como un RETURN TO MASTER te permite solucionar el problema, que causó el error.

Soy programador y yó sé eso: un problema o se soluciona con ésta ni ninguna otra.

>>> Generalmente, en una rutina de errores, si no podés solucionar el problema, lo mejor es que el sistema cancele y el operador avise del problema, que seguir intentando hacer, porque lo más probable es que siga agravando el problema y cada vez sea más irreparable.

A éso es a lo que me refiero. "Lo mejor es que el sistema cancele"; por éso es que pregunto: me recomiendas en el anterior post "...De una rutina de error puedes salir con RETURN (vuelve a la sentencia siguiente a donde se produjo el error)...", lo cual no me parece acertado, pues tú mismo lo dices "porque lo más probable es que siga agravando el problema".

Ahora: por si no lo habías notado: para cancelar es que estoy usando RETURN TO MASTER, por que mi escenario es que en el primer programa que se ejecuta (el supuesto Main.prg) hay un DO WHILE..ENDDO, de manera que regresa al menú de la aplicación.

[HernanCano]

Miguel:

>>> En fin, si funciona, dejalo, si lo querés menos consumista, pásate el READ EVENTS.

No es que lo "quiera"; es que me parece extraño que, si no está haciendo nada, el consumo de procesador sea el máximo sólo cuando lo minimizo, pues si no lo minimizo sino que, si lo tengo "activo"/en primer plano, el consumo es normal (es decir que no llega al 100%, cambia --es variable-- sí cuando lo pongo a hacer algo, pero ni siquiera así llega al 100%).

-------------------------------------------------------------
Por favor: no digo que sea mejor WAIT WINDOW, sino que noté que el consumo --cuando minimizado-- no se sube al 100%.
-------------------------------------------------------------
Estoy teniendo dificultades con mis pruebas de READ EVENTS. Luego les informo.

El martes, 10 de diciembre de 2013 18:43:06 UTC-5, Miguel escribió:

[Jorge L. Florez C.]

No es por el DO WHILE.. que suba el consumo de CPU sino lo que se encuentra dentro del DO WHILE....

Saludos

Jorge Florez

Lima - Perú

[Carlos Miguel FARIAS]

Como manejar errores y retornar al punto.

En alguna parte del código activo gestión de errores

ON ERROR DO manejoErrores bla bla

y

PUBLIC gbHayErrores

gbHayErrores =.F.

Antes de área crítica.

gbHayErrores =.F.

* comando sobre tabla

IF gbHayErrores

   = MessageBox => se pudrió

ELSE

* Sigue

ENDIF

En manejoErrores

veo si el error de tabla es solucionable (abrirla, recuperar indice, lo que sea reparable).

Si logro reparar hago un RETRY, reintento operación

Si no logro reparar hago

gbHayErrores = .T.

RETURN

Si usas el método error de la clase, el código de recupero se coloca en dicho método y la variable de control, en lugar de ser una variable pública puede ser una propiedad del formulario.

Y un control más fino, con try catch (que ya pasaron ejemplos).

En el bucle DO WHILE, como indicó el colega, si tienes algún formulario activo u otro proceso, el control lo tiene dicho proceso, y un formulario activo tiene algún control que tiene el foco, y eso lo maneja el S.O., que espera acciones de teclados o mouse o equivalente.

En dichos casos, mientras espera el evento teclado (18 veces por segundo) o al mouse, el control lo tomo el S.O. para otras cosas, y no computa como tiempo de CPU para tu aplicación.

Si no tienes nada activo, tu bucle va "girando" y cierra todo, borra variables, reconstruye el menu y dale que va, hasta que se activa algún formulario o proceso desde el menu.

Pero eso lo está haciendo sin parar (con lo que pasastes, no puedo ver si en alguna otra parte hay un READ EVENTS)

y Cuando llamas al MASTER, es como si hubieses recargado la aplicación desde cero, pero si el error era externo, no lo habrás recuperado si no tienes un manejo apropiado de lo que causa el error (por ejemplo, indices rotos)

Saludos: Miguel, La Pampa (RA)

[Hernan Cano]

Carlos Miguel:

>>> ...tu bucle va "girando" y cierra todo, borra variables, reconstruye el menu y dale que va, hasta que se activa algún formulario o proceso desde el menu.

No borro variables; sí reconstruyo el menú pues éso es lo que pretendo: ajustar el menú en caliente.

>>> Pero éso lo está haciendo sin parar (con lo que pasastes, no puedo ver si en alguna otra parte hay un READ EVENTS)

No lo hay, por éso les consulto.

>>> ... y cuando llamas al MASTER, es como si hubieses recargado la aplicación desde cero, ....

Se dice "regresar al MASTER".

>>> ... pero si el error era externo, no lo habrás recuperado si no tienes un manejo apropiado de lo que causa el error (por ejemplo, indices rotos).

En lo personal "no recupero de los errores" en la forma que tú indicas, pues por ejm si el problema es en un índice, el DBF se debe abrir de forma exclusiva, y a cualq hora del día no puede tener a certeza de que podré hacerlo (concurrencia!!!) (tengo entedido ---por lo que expresas--- que en el momento en que se produce el error, el programa "solito" hará REINDEX y/o INDEX ON).

[Carlos Miguel FARIAS]

Tu código original es

* Programa principal
* MAIN.prg
clea all
set dele on
clear
M.lSalir = .f.
do while .t.
   wait clear
   clear program
   do MyMenu
   if M.lSalir
      on shutdown quit
      close databases
      quit
   endif
enddo

Si cuando llamas al Main, y es llamar y no regresar.
Regresar es si volvés al punto en que se invocó el punto de error (retry) o a la sentencia siguiente (return, sin aditamentos). Un return to master, descarga el punto de llamada de la pila de procesos e invoca nuevamente al main.

Si llamas al main, al principio tienes un clear all, que si mal no recuerdo, borra todo y cierra todo.

Pero no importa si vuelvo o lo llamo, el tema es que el return vuelve al main (si no es al principio, donde?).

Y porque reajustar el menu, agregas o quitas opciones?

Y si el programa da un error (por indice roto), al volver el main, se soluciona algo?

Y si no tienes read events, son formularios modales? o tienen algún read por ahi?

Realmente, es evidente que si no se activa ningún formulario (supongo que modales) el bucle no se detiene y continuamente regenera uso de cpu.

Según M$, el return to master es aplicable a vfp 3 (tres) y anteriores ver http://support.microsoft.com/kb/119900/es

En http://doughennig.com/papers/..%5CPub%5Cerrorh.pdf
que pasé el otro día, en página 3 dice (traducido por Google)
"Otra opción es utilizar el RETURN TO MASTER o RETURN <PROGRAM> para salir del
programa que causó el error y volver al programa principal o alguna otro programa específico. Usted necesita tener cuidado con esta opción, ya que podría dejar el sistema en un estado desordenado: seguirán existiendo formas y ventanas, tablas o cursores aún estarán abiertos, etc
Es una buena idea para limpiar esas cosas tanto como sea posible antes de utilizar el comando RETURN ..."

O sea, que la opción que utilizas, es potencialmente peligrosa (deja mucha basura dando vuelta).

Si ves en https://groups.google.com/forum/#!topic/mundovisualfoxpro/7q6vaYMsals (30/07/2011)

Ya habías hecho la pregunta, y se te respondió lo mismo (fui yo?)

En http://books.google.com.ar/books?id=iF97jVKcqhEC&pg=PA488&lpg=PA488&dq=return+to+master+visual+foxpro&source=bl&ots=6ux03FuBtS&sig=b40GjeMjv5GFZJP6p0QZslF_eXw&hl=es&sa=X&ei=IumoUpHDJofmkAfV7oB4&ved=0CGIQ6AEwBg#v=onepage&q=return%20to%20master%20visual%20foxpro&f=false

indica que el RETURN TO Master es peligroso (y la referencia es 10 veces más importante de lo que pueda decir yo)

Y si no quieres tener consumo de recursos (o que te diga eso el SO) usa read events.

Y si queres llorar, llorá.

Para mi, c'est fini.

Saludos: Miguel, La Pampa (RA)

[edgar suarez kummers]

Estimado Carlos Miguel:

Yo utilizo RETURN TO MASTER en el caso de que consultando las tablas parametrizadas que debe tener la aplicación no hayan llenado alguna o algunas y previo un WAIT WINDOW "bla, bla, bla ". 

Entonces la aplicación vuelve a la pantalla donde está el MENU.

No uso el RETURN TO MASTER para errores, sino para situaciones que al no encontrarlas el programa, generarían un error.

Y lo hice así porque RETURN TO MASTER funciona como un buzo que necesita salir a la superficie, sin importar cuantas BRAZAS (programitas) esté en profundidad.

Y lo hice para evitar el molesto LA APLICACIÓN SE CERRARÁ porque WAIT WINDOW "bla,bla,bla".

No utilizo el TRY/bla,bla,bla porque creo que no lo necesito, o sea hago las aplicaciones para que no marquen en lo posible errores.

Si, utilizo el ON ERROR do salida.prg / código de archivos a encontrar /ON ERROR 

Porque si al no encontrar un archivo y saliendo el aviso CONTINUAR entonces se violentaría la seguridad que tengo, y son varias, y las detecto con la existencia de archivos que utilizan encriptación.

No está de más reconocer en el ciudadano de LA PAMPA un verdadero maestro. Felicitaciones.

Saludos

edgar suárez kummers

[Carlos Miguel FARIAS]

Tal como le dije a Hernan, si funciona, no se toca, pero evidentemente, documente donde todos dicen que no es recomendable.

Saludos: Miguel, La Pampa (RA)

[Hernan Cano]

Carlos:

>>> Si llamas al MAIN, al principio tienes un CLEAR ALL, que si mal no recuerdo, borra todo y cierra todo.

Sí, pero el CLEAR ALL sólo se ejcuta la primera vez que se ejecuta, no luego de regresar de un RETURN TO MASTER.
El error se produce luego de un error (???????), pero dentro de "do MyMenu", y al regresar pasa a la línea sgte que es "if M.lSalir" y sgtes.

>>> Pero no importa si vuelvo o lo llamo; el tema es que el RETURN vuelve al MAIN (si no es al principio, donde?).

Sí, vuelve al principio, pero no ejecuta el CLEAR ALL como mencionas; ejecuta la línea sgte a donde va, y va en "do MyMenu".

>>> Y porque reajustar el menú; agregas o quitas opciones?

Sí. Pero éso es otro tema.

>>> Y si el programa da un error (por índice roto), al volver el MAIN, se soluciona algo?

Por favor, amigo, no se soluciona. Nadie ha dicho éso. ¿Por qué insistes en ello?

Yo nunca he dicho que se soluciona. Eres tú (y otros) que lo expresan como si yo lo hubiera dicho... o no sé qué.....

>>> Y si no tienes READ EVENTS, ¿son formularios modales? o ¿tienes algún READ por ahí?

No te sé contestar, pero lo intentaré.

Para mis formularios debí ejecutarlos (los ejecuto) con .Show(1) o con "WindowType=1", pues de otra forma no se "veían".

((este respuesta te la doy porque veo en las ayudas que WindowType=1 se refiere a forms "modales")).

>>> ... es evidente que si no se activa ningún formulario (supongo que modales) el bucle no se detiene.

¿Sabes dónde hay info al respecto?

A mí me parece que sí se detiene, en el menú, a esperar que escoja alguna opción ((pero sólo me parece ---porque así lo veo---)).

>>> Según M$, el return to master es aplicable a vfp 3 (tres) y anteriores ver http://support.microsoft.com/kb/119900/es

Lamento contradecirte, colega: No veo en esta URL que se menciona sobre la limitación de VFP3. Por el contrario: es aplicable HASTA la v6 (pero por que esta info apareción en la época de VFP6, no que no se pueda utilizar en superiores).

 

>>> Es una buena idea para limpiar esas cosas tanto como sea posible antes de utilizar el comando RETURN ..."

Gracias, amigo, por la recomendación. La aplico.

[HernanCano]

Perdón.
Debí eliminar un mensaje que era el mismo anterior, pero no estaba completo.
Pido disculpas si ello es inadecuado.

[HernanCano]

Ciguel:

>>> Y si no quieres tener consumo de recursos (o que te diga éso el SO), usa READ EVENTS.

Tu apreciación es que el consumo de recursos es por usar DO WHILE .T. a cambio de READ EVENTS.
Lo tendré en cuenta.

>>> ... indica que el RETURN TO Master es peligroso....

Sí, específicamente con el código de limpieza de las procedures "saltadas". Como te digo en la anterior respuesta: soy consciente de ello y hago código de limpieza (evidentemente sé que puedo mejorar lo que hago, me alerto más).

No problem.  C'est fini.

[Hernan Cano]

El tema de READ EVENTS surgió por que las teclas Tab y Enter no funcionan en la implementación de la FoxRibbon de Guillermo Carrero que

publiqué.

Les solicito ir allá, pues el tema quí (uso de procesador) quedó resuelto.

Gracias, amigos.

[HernanCano]

Qué extraño: No encuentro el botón para "Cerrar tema".

[Carlos Miguel FARIAS]

Será porque falta el READ EVENTS :-)

[HernanCano]

Sí, Miguel; seguramente es por éso.

Señor admor: ¿será que una etiqueta de Cerrado podría funcionar?

Gracias.

[Jorge Kiernan]

A ver si te sirve. el final de mi rutina de errores, luego de haber notificado el problema al usuario y guardado una serie de datos para mi auditoria, dice :

WAIT WINDOW ' Salida forzada del SISTEMA ' NOWAIT

* corre un rollback por cada transacción abierta en el sistema

lntxnlevel = TXNLEVEL()

for i = 1 to lntxnlevel 

    rollback

endfor 

CANCEL

CLOSE ALL

CLEAR ALL

CLEAR EVENTS 

return to master

[Hernan Cano]

Sí, Jorge; está bien.

Algo similar hago yo.

El problema es que me están diciendo que no utilice RETURN TO MASTER "por que es peligroso" (yo prefiero decir "por que es dudosa su seguridad") y que no utilice DO WHILE .T. a cambio del READ EVENTS.

[Mario López]

@Hernan: mis 2 centavos:

- "La Forma Correcta" de trabajar con VFP es usar READ EVENTS / CLEAR EVENTS. Cualquier
otra forma de trabajar implica una espera activa (busy wait) que hace uso innecesario
del procesador. Esto es así en VFP como en cualquier otra plataforma de desarrollo de
aplicaciones GUI, te paso un par de ejemplos de las que uso habitualmente:

# Python + wxPython:
import wx

app = wx.App(redirect=True)
top = wx.Frame(None, title="Hola!", size=(300,200))
top.Show()
app.MainLoop()      #### app.exec_() es el event loop

# Python + PyQt:
import sys
from PyQt4 import QtGui

app = QtGui.QApplication(sys.argv)

w = QtGui.QWidget()
w.resize(300, 200)
w.setWindowTitle('Hola!')
w.show()

sys.exit(app.exec_())   #### app.exec_() es el event loop

Fijate también en http://en.wikipedia.org/wiki/Event_loop


- El RETURN TO MASTER está desaconsejado (copio un bloque de Hacker's Guide to VFP)
...
The TO clauses are a little more tricky, and we generally avoid them because they can violate good structured programming principles. RETURN TO MASTER blasts through the entire program stack, returning control to the topmost program. Any other code waiting to execute in the intervening routines is ignored. This has the potential of leaving your application in an unstable condition, and we typically use this only in dire situations, such as deep in an error handler.

RETURN TO FunctionName lets you do something almost as dangerous—leapfrog over the calling routines to a particular place in the calling stack. If you design your application exactly right, you may get away with this, but if you're expecting cleanup code to fire in the routines skipped over to restore the environment, you could be out of luck.
...


- El hecho de usar READ EVENTS / CLEAR EVENTS no implica que no puedas hacer un bucle
externo al READ EVENTS y vuelvas a la instrucción siguiente con CLEAR EVENTS y luego
sigas con el bucle:

---
CLEAR ALL

PUBLIC _Salir
ON ERROR DO OnError

_Salir = .F.
DO WHILE ! _Salir
    WAIT WINDOW ("Bucle principal: " + TIME()) TIMEOUT 2
    CLEAR PROGRAM
    oForm = CREATEOBJECT("xForm")
    oForm.Show(1)        && Modal
    READ EVENTS
ENDDO

WAIT WINDOW "Salio del bucle principal"
ON SHUTDOWN QUIT
CLOSE DATABASES
* QUIT

RETURN


DEFINE CLASS xForm AS Form
    ShowWindow = 2        && As Top Level Form
    AutoCenter = .T.

    ADD OBJECT cmd001  AS CommandButton WITH Top = 10, Caption = "\<1"
    ADD OBJECT cmd002  AS CommandButton WITH Top = 40, Caption = "\<2"
    ADD OBJECT cmdExit AS CommandButton WITH Top = 70, Caption = "\<Salir", Cancel = .T.
 


    PROCEDURE cmd001.Click

    * Genero un error a ver que pasa
    TRY
        nVar = nVarInexistente
    CATCH
        WAIT WINDOW "Error (TryCatch)" TIMEOUT 2
        RELEASE ThisForm
        CLEAR EVENTS
    ENDTRY
  
    RETURN
  

    PROCEDURE cmd002.Click

    nVar = nVarInexistente   && Genero un error
  
    RETURN
  

    PROCEDURE cmdExit.Click
    _Salir = .T.
    RELEASE ThisForm
    WAIT WINDOW "Despues de Release"
    CLEAR EVENTS
    WAIT WINDOW "Despues de CLEAR EVENTS"     && Aca no llega nunca
    ENDPROC
ENDDEFINE



PROCEDURE OnError

WAIT WINDOW "Error (OnError)" TIMEOUT 2

TRY
    _Screen.ActiveForm.Release()
CATCH
ENDTRY   

CLEAR EVENTS

ENDPROC
---

Con este esquema, no veo la necesidad del DO WHILE + WAIT WINDOW que implica espera activa.

HTH
Mario

[HernanCano]

Sí, Mario. Muchísimas gracias.

Como habrás notado, no soy yo quien pide no usar DO WHILE.... Son los colegas que me recomiendan éso. Pero he pensado en una solución como la que mencionas: combinar READ EVENTS con DO WHILE y que el ciclo esté basado en un avble, tal como  _Salir.  Bien, gracias.

Por el momento estoy haciendo una pruebas para incorporar a mi esquema de trabajo el comando READ EVENTS. Cuando lo entienda seguro que podré "combinarlos".

Dentro de poco les informo mis acercamientos.

Gracias.

[Mario López]

@Hernan: mmm, me parece que no te dijeron "no usar DO WHILE" sino "no reemplazar el bucle de eventos READ
EVENTS" con un DO WHILE.

Por lo demás, no me parece un esquema muy estándar pero no le veo problema a tener un DO WHILE que incluya
el READ EVENTS y que vuelva al mismo con CLEAR EVENTS (no con RETURN TO MASTER), pero como dicen
"YMMV"

HTH
Mario
---

[Hernan Cano]

Correcto, Mario:

quisiera usar "READ EVENTS y que vuelva al mismo con CLEAR EVENTS"; pero en el adjunto te demuestro que no regresa al READ EVENTS, sino que se queda (bloqueado) en él.

[Miguel Canchas]

Acabdo de modificar tu archivo main.prg

 

Cambialo por este código que te paso :

 

 

** Programa principal del Ejemplo de Uso de la FoxRibbon

* MAIN.prg

* Nov-2013

 

#define _CR chr(13)

#include MessBox.H

 

 

on error do errHandler WITH ERROR(), MESSAGE(), MESSAGE(1), PROGRAM(), LINENO()

on shutdown do Terminar

 

SET MULT Off

SET SYSM OFF

set esca off

set safe off

set dele on

set cons off

set conf off

set talk off

set devi to scre

set prin off

set prin to

SET STRICTDATE TO 0

set date YMD    && aaaa.mm.dd

set cent on

set excl Off    && por defecto red

*SET ANSI OFF

*SET EXACT Off

 

set deve on       && ¨.exe?

set noti on

**

**

set default to JustPath(fullpath(sys(16)))

 

 

clear

 

do GenRibbon with "RIBBON_MENU.DBF",.T.

 

_Screen.AddProperty([lSalir],.f.)

_Screen.TitleBar = 0 && Off

 

   do RIBBON_MENU.PRG

   read events

 

 

PROCEDURE errHandler

   lPARAMETER merror, mess, mess1, mprog, mlineno

  

   CLEAR

   local M.xCad

   M.xCad =;

     'Error number : ' + transform(M.merror)+_CR;

    +'Error message: ' + M.mess+_CR;

    +'Line of code with error: ' + M.mess1+_CR;

    +'Line number of error: ' + transform(M.mlineno)+_CR;

    +'Program with error  : ' + M.mprog+_CR

     

      **MB_RETRYCANCEL   5    && Retry and Cancel buttons

      local M.nResp

      M.nResp = MessageBox(M.xCad,MB_RETRYCANCEL,"---Manejador simple de errores---")

      do case

      case M.nResp = IDRETRY     &&    4       && Retry  button pressed

          retry

      case M.nResp = IDCANCEL    &&    2       && Cancel button pressed

          close databases

            ** hay otros comandos para CleanUp      

           

            set sysm to defa

            set debu on

            set step on

           

        CLEAR EVENTS

            *return to master

           && con estas dos instrucciones la app se bloquea en la instrucción READ EVENTS

               && y si suprimo 'return to master' dejando sólo CLEAR EVENTS, regresa a la línea sigte a la que produjo el error.....

      endcase

     

ENDPROC

 

 

**

[Mario López]

@Hernan: ¿adjunto? en este post no vi ninguno, si te referís al del FoxRibbon no te puedo ayudar porque no lo usé nunca.

Saludos,
Mario
---

[Hernan Cano]

En el adjunto que pasé en su momento.....

Perdón, amigo....

Te lo replico.

[Hernan Cano]

Gracias, Miguel.

- Veo que habilitaste varias instrucciones que yo tenía deshabilitadas precisamente para simplificar el ambiente: las que están desde "SET MULT Off" hasta "set noti on".

- También habilitas la generación de la ribbon con "do GenRibbon with "RIBBON_MENU.DBF",.T." que tabién había deshabilitado para simplificar el ambiente.

- Suprimiste el "DO WHILE"

2013/12/16 Miguel Canchas <mcan...@ximesa.com>

[Hernan Cano]

Gracias, Miguel.

- Veo que habilitaste varias instrucciones que yo tenía deshabilitadas precisamente para simplificar el ambiente: las que están desde "SET MULT Off" hasta "set noti on".

- También habilitas la generación de la ribbon con "do GenRibbon with "RIBBON_MENU.DBF",.T." que tabién había deshabilitado para simplificar el ambiente.

- Suprimiste el "DO WHILE" y algunos comandos. Supondré que ésta es tu recomendación.

- En el manejador de errores, suprimes el "return to master". Supondré que ésta es tu recomendación.

[edgar suarez kummers]

Buenas Hernán:

Miré el código que corrigió Miguel Canchas .....

En vez de todo eso de Ribbon sería mejor que hicieras

Do elmenu.mpr

y luego sí

Read events

Ya dentro del menú llamas a los programas del Ribbon.

edgar suárez kummers

[HernanCano]

Miguel:
Si ejecuto tu recomendado, obtengo lo sgte:

- Al generar el error (MaeClientes - Nuevo), con tu idea, el programa luego de ejecutar el CLEAR EVENTS, regresa a la sgte línea donde se produjo el error ("wait window 'revisar si llegó hasta aquí' nowait noclear"), lo cual es peligrosísimo, y es precisamente lo que se debe evitar a toda costa (si hay un error, el programa no puede seguir campante............................¿me perdí de algo?.................).

- Evidentemente al estar dentro de un ambiente de trace "SET STEP ON", le digo que siga y el programa se para en Oform.Show(1) ((en pruebas hasta hace unos minutos, se paraba en CLEAR EVENTS)). Siempre el programa completo se bloquea y debo cerrarlo desde el admor de tareas.

[edgar suarez kummers]

Hernán, el que te envié me ha funcionado bien siempre.

Llama al programa de Ribbon desde un menu.

Yo le quitaría el manejo de errores del MAIN

Y si crees que se vaya a producir un error entonces dentro de tus PRG colocas

On error do errores.prg

* donde crea que se va a producir un error

On error

y en el errores.prg se coloca

wait window "el error es por esto y aquello "

return to master

edgar suárez kummers

[HernanCano]

Edgar:
Con "do RIBBON_MENU.PRG" se cumple el mismo objetivo de lo que propones. Así está la propuesta de él y aasí lo estoy comprobando.

[Hernan Cano]

Ya tengo un error generándose en "Maestro de Clientes - Nuevo", con DEBUG incluido. Te pido que lo ejecutes y veas cómo pasa por los diferentes comandos.

Luego de Cancelar, se regresa a la línea sgte a donde se rodujo el error, o cual no lo podemos permitir como programadores, pues si hay un error entonces el procedimiento debe parar, lo que hago con Cancelar --- pero que se regrese al menú, no que siga muy feliz y campante.

Y como vas a notar se bloquea en el programa principal: tengo que cerrar desde el admor de tareas.

[Miguel Canchas]

Cámbialo ahora por este, estoy cambiando tu procedure de error :

 

** Programa principal del Ejemplo de Uso de la FoxRibbon

* MAIN.prg

* Nov-2013

 

#define _CR chr(13)

#include MessBox.H

 

 

DOEVENTS

 ON ERROR DO errhand WITH ERROR( ), MESSAGE( ), MESSAGE(1), SYS(16), LINENO( ), PROGRAM()

 

SET MULT Off

SET SYSM OFF

set esca off

set safe off

set dele on

set cons off

set conf off

set talk off

set devi to scre

set prin off

set prin to

SET STRICTDATE TO 0

set date YMD    && aaaa.mm.dd

set cent on

set excl Off    && por defecto red

 

set default to JustPath(fullpath(sys(16)))

 

do GenRibbon with "RIBBON_MENU.DBF",.T.

 

_Screen.AddProperty([lSalir],.f.)

_Screen.TitleBar = 0 && Off

 

do RIBBON_MENU.PRG

read events

 

FUNCTION errhand

 PARAMETER merror, mess, mess1, mprog, mlineno, prowram

 msgexit = "Número de error                 : "+LTRIM(STR(merror))+CHR(13)+"Mensaje de error                : "+ALLTRIM(mess)+CHR(13)+"Línea de código con error  : "+mess1+CHR(13)+"Número de línea del error  : "+LTRIM(STR(mlineno))+CHR(13)+"Programa con error            : "+mprog+CHR(13)+prowram

 lnanswer = MESSAGEBOX(msgexit, 050, "El Error ya fue Registrado, en Breve se Comunicarán con Ud.")

 CREATE CURSOR v_error (nro_er C (6), msg_er C (80), licod_er C (6), nroli_er C (6), prg_er C (80), dia D)

 IF FILE("Errores.txt")

    SELECT v_error

    APPEND FROM ("Errores.txt") TYPE SDF

 ENDIF

 INSERT INTO v_error (nro_er, msg_er, licod_er, nroli_er, prg_er, dia) VALUES (ALLTRIM(STR(merror)), mess, mess1, ALLTRIM(STR(mlineno)), mprog, DATE())

 COPY TO ("Errores.txt") TYPE SDF

 USE IN v_error

 DO CASE

    CASE lnanswer=3

        CANCEL

    CASE lnanswer=4

       RETRY

    CASE lnanswer=5

       RETURN .T.

 ENDCASE

ENDFUNC

 

 

[Jorge L. Florez C.]

Tan dificil es usar el FoxRibbon?... no tiene manual?

Saludos

Jorge Florez

Lima - Perú

2013/12/16 Miguel Canchas <mcan...@ximesa.com>

[HernanCano]

Miguel:
Agradezco tu interés por ayudarme.

Al presentarse un error estás dando tres opciones: Abortar, Reintentar, e Ignorar.

1. Al Abortar se ejecuta "CANCEL"; sin embargo no es muy elegante que ante cualquier mensaje de error (la impresora no está lista, registro ocupado, etc) se tenga que matar todo el programa. Sobre todo si es la opción por defecto.

2. Al Reintentar se ejecuta "RETRY", lo cual es acertado.

3. Al Ignorar se ejecuta "RETURN .T.", pero ésto es algo que no puedo permitir, pues las sentencias sgtes a la que produjo el error dañarán más la información de los datos (o de lo que se esté haciendo).
En teoría, la opción Ignorar sólo la habilito para un usuario de sistemas como yo mismo --alguna vez lo intenté, pero realmente no fue prácrtico ni necesario y abolí la opción definitivamente--.

Ahora con la opción Cancelar quiero que el programa vuelva al menú de la app, para que el usuario decida si corrige lo que generó el arror (reindexar archivos, esperar a instalar la impresora, etc) o si ejecuta otra opción del programa.

Me faltaba recordarte: en la opción Cancelar del admor de errores es que ejecuto el "RETURN TO MASTER" o también --quizá para este caso-- "RETURN TO MAIN" pues el prg se llama así -y tal vez esté ejecutando desde Fox6Command o Fox9Command).

Estoy armando un ejemplo enfocado a menú con el uso de CLEAR EVENTS  y RETURN TO MASTER para que lo analicemos.

Recuerda que este tema ya está cerrado.

El lunes, 16 de diciembre de 2013 14:31:12 UTC-5, Miguel Canchas escribió:

Cámbialo ahora por este, estoy cambiando tu procedure de error :

DO CASE

[Miguel Canchas]

Ningun sistema este excento de errores…Windows es uno de ellos.  Cuando te sale un mensaje de error te muestra 3 opciones, si CANCELAR, REINTENTAR o IGNORAR…yo trabajo con sistemas que solo te dan la opción de cancelar…nada de intentar o ignorar.. y si al usuario le sale un error hace un print screen y nos lo envían para revisarlo. No te hagas bolas…..el usuario sabe que si cancela se cierra, si reintenta volverá a ejecutarlo, si ignora no hace nada….

 

MK

 

 

De: HernanCano [mailto:jherna...@gmail.com]
Enviado el: lunes, 16 de diciembre de 2013 03:50 p.m.
Para: publice...@googlegroups.com
CC: HernanCano; Miguel Canchas
Asunto: Re: [vfp] Re: Sobre rendimiento y uso de procesador por app VFP

 

Miguel:

[HernanCano]

El admor de errores que uso desde 1990 sólo tiene dos opciones: Reintentar y Cancelar.

- Con Reintentar ejecuto RETRY

- Con CANCELAR ejecuto RETURN TO MASTER (luego de Close Databases y algo más de CleanUp).

Pienso que ejecutar CANCEL no es apropiado sólo por "La impresora no está lista" o "Registro ocupado" o "Archivo ocupado".

Gracias por participar.

[Hernan Cano]

El ejemplo que muestro facilita el uso de Foxribbon, ya que como está en el portal, sólo puede ser usado de forma "visual".

Lo que pasa es que algunos colegas chistaron mi manejo de un "DO WHILE" en el programa inicial y me pidieron cambiarlo por READ EVENTS.

Yo les repliqué que no era compatible con mi manejo de errores, pues uso RETURN TO MASTER; y entonces me dicen y repiten q

2013/12/16 Jorge L. Florez C. <jorgel...@gmail.com>

[Hernan Cano]

El ejemplo que muestro facilita el uso de Foxribbon, ya que como está en el portal, sólo puede ser usado de forma "visual".

Lo que pasa es que algunos colegas chistaron mi manejo de un "DO WHILE" en el programa inicial y me pidieron cambiarlo por READ EVENTS.

Y como también el alcance que muestro no admite el uso de las teclas Tab ni Enter sobre los botones de la ribbon, informan que todo está ligado.

Yo les repliqué que READ EVENTS no era compatible con mi manejo de errores, pues uso RETURN TO MASTER; y entonces me dicen y repiten que READ EVENTS, CLEAR EVENTS.

Estoy haciendo un "demo" para demostrar que READ EVENTS/CLEAR EVENTS no funciona con mi admor de errores.

Pero la FoxRibbon ya funciona como se necesita.

Espérame un momento y te paso lo que logré.

2013/12/16 Jorge L. Florez C. <jorgel...@gmail.com>

Tan dificil es usar el FoxRibbon?... no tiene manual?

Saludos

Jorge Florez

[Miguel Canchas]

“Y como también el alcance que muestro no admite el uso de las teclas Tab ni Enter sobre los botones de la ribbon, informan que todo está ligado.”

 

Que manera de complicarse la vida, en estos tiempos ya no se usa como antes que era con las flechas de direccion, en tiempos modernos se usa el mouse...

 

Acaso vez que en el office permite desplazarse por el menu con las teclas de direccion ?? No pues, no lo hace...

 

MK

 

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Hernan Cano
Enviado el: lunes, 16 de diciembre de 2013 04:59 p.m.
Para: publice...@googlegroups.com
Asunto: Re: [vfp] Re: Sobre rendimiento y uso de procesador por app VFP

 

El ejemplo que muestro facilita el uso de Foxribbon, ya que como está en el portal, sólo puede ser usado de forma "visual".

[HernanCano]

Disculpa, Miguel.

Definitivamente había tomado la decisión de seguir con la FoxRibbon como lo logré: Sin READ EVENTS, con RETURN TO MASTER y sin la teclas Tab ni Enter.

En este momento estoy ajustando dos ejemplos: uno para demostrar que Read Events falla cuando hay un error (sólo funciona bien si se le da CANCEL), y el ejemplo de uso de FoxRibbon como funciona mejor de acuerdo a mis acercamientos.

Esta apreciación tuya me da un motivo más.

Pero me queda la duda de por qué en la FoxRibbon original sí funcionan.

Gracias. Miguel.

Seguimos en contacto.