Depurar aplicación paso a paso
2,057 views
Skip to first unread message
alexana
Mar 16, 2013, 1:47:10 PM3/16/13
to publice...@googlegroups.com
Me gustaría saber si existe alguna manera de depurar la aplicación paso a paso; en concreto, cuando la ejecuto, empieza a gargar, luego se queda como parada y luego sigue cargando.
Me interesaría ver lo que va cargando, pero paso a paso, sin que salgan formularios ni nada. Espero haberme explicado.
Espero vuestra ayuda. Gracias
Alexana
edgar suarez kummers
Mar 16, 2013, 1:58:32 PM3/16/13
to publice...@googlegroups.com
La única forma que conozco y uso es hacer impresiones parciales sobre la pantalla con WAIT WINDOW "vas mejorando" .... WAIT WINDOW "sigue así, no desfallezcas" .... WAIT WINDOW "Estás cerca del triunfo"
edgar suarez kummers
saludos
Please look my LINKS --- What I offer ---
ingeniero electrónico
matrícula 11714
diseño de software y ensamble de cuadros de control
cel Colombia: 3176992038
tel fijo Bogotá: 3126100
ultraton500
Mar 16, 2013, 3:00:29 PM3/16/13
to publice...@googlegroups.com
Hola Alexana, mientras esperas una mejor respuesta podrías ir leyendo esto que es lo primero que salió en google cuando busqué "depurar aplicación vfp":
Espero te sea de utilidad.
Saludos,
Javier.
Pablo Daniel Lissa
Mar 16, 2013, 4:57:22 PM3/16/13
to publice...@googlegroups.com
Hola:
Deberías familiarizarte con el uso del Depurador, que se abre al seleccionar Herramientas -> Depurador (o Tools -> Debuger). Con esta herramienta se puede seguir código, ver el valor de variables, evaluar expresiones en tiempo de ejecución, entre otras cosas.
Para activar el seguimiento paso a paso deberías poner puntos de interrupción o el comando SET STEP ON dentro de tu código.
Ojo, los procesos que quieras analizar debes identificarlos previamente. Por ejemplo, si tienes un programa PRG de inicio, incluyes SET STEP ON en ese PRG. Si quieres seguir la secuencia de carga de un formulario, debes tener conocimiento del orden en que se disparan los eventos; por ejempo, si pones SET STEP ON en el evento Init, te habrás perdido de seguir lo que pasa en el evento Load, que se dispara antes.
Saludos.
Deberías familiarizarte con el uso del Depurador, que se abre al seleccionar Herramientas -> Depurador (o Tools -> Debuger). Con esta herramienta se puede seguir código, ver el valor de variables, evaluar expresiones en tiempo de ejecución, entre otras cosas.
Para activar el seguimiento paso a paso deberías poner puntos de interrupción o el comando SET STEP ON dentro de tu código.
Ojo, los procesos que quieras analizar debes identificarlos previamente. Por ejemplo, si tienes un programa PRG de inicio, incluyes SET STEP ON en ese PRG. Si quieres seguir la secuencia de carga de un formulario, debes tener conocimiento del orden en que se disparan los eventos; por ejempo, si pones SET STEP ON en el evento Init, te habrás perdido de seguir lo que pasa en el evento Load, que se dispara antes.
Saludos.
Fernando D. Bozzo
Mar 16, 2013, 9:01:42 PM3/16/13
to publice...@googlegroups.com
Hola Alexana:
Creo que te conviene cambiar la forma de ver el problema y ganar tiempo. El depurador no sirve para eso, seguir las instrucciones paso a paso solo se justifica para buscar un error, no un cuello de botella, y por lo que comentás estás buscando un cuello de botella, o sea un punto --o más-- de la aplicación donde hay algún proceso que es lento.
Para esto creo que no hay nada mejor que el SET COVERAGE, que desde la versión 8 --si mal no recerdo-- permite tener la cobertura de código incluso de un ejecutable, aunque este comando existe casi desde los inicios de Fox.
Básicamente lo que hace es escribir un log con cada línea de código que se ejecuta, hasta que desactives el COVERAGE o hasta que cierres la sesión de FoxPro. Pero a diferencia de la creencia popular, el archivo log generado no es para mirarlo directamente, porque puede contener miles de líneas, sino para analizar con otra herramienta que trae FoxPro, que se llama Coverage Profiler (en el menú Herramientas, por abajo de todo, cerca del Debugger). También hay una versión mucho mejor y más potente de este analizador en CODEPLEX, donde se hospedan los proyectos OpenSource para VFPX, Sedna, etc.
Esta herramienta, lo que te permite hacer, es analizar todo el log generado y mostrarte 2 vistas: Una vista --por defecto-- que permite saber qué lineas de código se ejecutaron y cuáles no dentro de cada clase (de las que se muestra una lista seleccionable) y otra vista (con un icono de un rayo) que es la que te va a interesar, que muestra los tiempos de ejecución de cada uno de los módulos, y dentro de los módulos los tiempos de cada línea ejecutada. Todos los tiempos en segundos, con resolución de cienmilésimas, y encima con barras de color (amarillo) para resaltarlos visualmente. Esta es una herramienta que todo programador debería usar para afinar sus aplicaciones.
Es ésta la herramienta que deberías usar para encontrar rápidamente los cuellos de botella. La forma más rápida de hacerlo es comenzar por el módulo principal a analizar y ver su tiempo total de ejecución, luego irse adentrando en el mismo, e ir viendo los tiempos de los procesos internos, hasta que encuentres el que te interesa.
Si bien FoxPro trae un Coverage Profiler nativo, te recomiendo el que hay disponible dentro del Proyecto XSource de CodePlex en esta página:
http://vfpx.codeplex.com/
Saludos!
Creo que te conviene cambiar la forma de ver el problema y ganar tiempo. El depurador no sirve para eso, seguir las instrucciones paso a paso solo se justifica para buscar un error, no un cuello de botella, y por lo que comentás estás buscando un cuello de botella, o sea un punto --o más-- de la aplicación donde hay algún proceso que es lento.
Para esto creo que no hay nada mejor que el SET COVERAGE, que desde la versión 8 --si mal no recerdo-- permite tener la cobertura de código incluso de un ejecutable, aunque este comando existe casi desde los inicios de Fox.
Básicamente lo que hace es escribir un log con cada línea de código que se ejecuta, hasta que desactives el COVERAGE o hasta que cierres la sesión de FoxPro. Pero a diferencia de la creencia popular, el archivo log generado no es para mirarlo directamente, porque puede contener miles de líneas, sino para analizar con otra herramienta que trae FoxPro, que se llama Coverage Profiler (en el menú Herramientas, por abajo de todo, cerca del Debugger). También hay una versión mucho mejor y más potente de este analizador en CODEPLEX, donde se hospedan los proyectos OpenSource para VFPX, Sedna, etc.
Esta herramienta, lo que te permite hacer, es analizar todo el log generado y mostrarte 2 vistas: Una vista --por defecto-- que permite saber qué lineas de código se ejecutaron y cuáles no dentro de cada clase (de las que se muestra una lista seleccionable) y otra vista (con un icono de un rayo) que es la que te va a interesar, que muestra los tiempos de ejecución de cada uno de los módulos, y dentro de los módulos los tiempos de cada línea ejecutada. Todos los tiempos en segundos, con resolución de cienmilésimas, y encima con barras de color (amarillo) para resaltarlos visualmente. Esta es una herramienta que todo programador debería usar para afinar sus aplicaciones.
Es ésta la herramienta que deberías usar para encontrar rápidamente los cuellos de botella. La forma más rápida de hacerlo es comenzar por el módulo principal a analizar y ver su tiempo total de ejecución, luego irse adentrando en el mismo, e ir viendo los tiempos de los procesos internos, hasta que encuentres el que te interesa.
Si bien FoxPro trae un Coverage Profiler nativo, te recomiendo el que hay disponible dentro del Proyecto XSource de CodePlex en esta página:
http://vfpx.codeplex.com/
Saludos!
alexana
Mar 17, 2013, 6:53:19 AM3/17/13
to publice...@googlegroups.com
Gracias a todos, por vuestra respuesta. La utilización del coverage parece muy interesante. Me pongo manos a la obra.
Muchas gracias de nuevo a todos por vuestra ayuda.
Alexana
ultraton500
Mar 17, 2013, 2:58:59 PM3/17/13
to publice...@googlegroups.com
Muy interesante tu post Fernando, muchas gracias por el dato.
Saludos cordiales,
Javier.
Reply all
Reply to author
Forward
0 new messages