![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Buscar | Temas de Hoy | Marcar Foros Como Leídos |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
||||
|
||||
|
Hola,
Lepe, muchas gracias por tu información, que me ha servido para probar el "JclDebug" e incluso implementarlo (a partir de uno de los ejemplos que se pueden encontrar) en XEditor. ¿Para qué demonios? Ahí está el caso. Este programa, cuando se produce una excepción, muestra al usuario un mensaje con la misma y le da la posibilidad de enviarme por correo un reporte de error. Entonces, me he dicho, hombre, si añades la información del "JclDebug" el reporte de error contendrá bastante más información, que podrá resultar muy útil para tratar de solucionar posibles problemas en el programa. Y dicho y hecho, más o menos, he conseguido que el reporte incluya la información que puede proporcionar en caso de excepción el "JclDebug". Ahora bien, parece ser que no puedo utilizar el compresor de ejecutables para comprimir el del programa susomentado, porque, entonces el "JclDebug" no funciona como debe y al producirse la excepción e intentar conseguir la información correspondiente se produce a su vez otra excepción y... para qué seguir. ![]() El programa ocupa ahora unos 3,44 MB, y comprimido se quedaba en menos de uno, pero, no es esto del todo importante, puesto que el programa instalador comprime el ejecutable (y el resto de archivos) sin que afecte al "JclDebug" y, al cabo, estamos hablando de que antes de implementar lo dicho el programa de instalación ocupaba unos 1,41 MB y ahora se quedaría en 1,95 MB. Puesto que la ejecución del programa no se ve ralentizada (es aquello de que ahora, incluso, no es preciso descomprimir el ejecutable cada que se pone en marcha el programa) y al convencerme el asunto como para pensar en publicar el programa de este modo, asumiendo que no irá comprimido y que el asistente de instalación ocupará un poco más, me pregunto todavía... ¿Merece la pena el reporte de error? ¿Es necesario o puede ser útil cuando el programa ya se ha publicado, quiero decir, cara al usuario? ¿Debería usar el "JclDebug" únicamente cuando esté trabajando yo mismo en el programa y dejar de usarlo a la hora de publicar el mismo? ¿Puedes tú mismo o alguien que esto lea decirme algo que me aclare un poco estas dudas que tengo? Muchas gracias de antemano. Si véis que me dejo algo en el tintero, me lo hacéis saber y veremos cómo hago para explicar lo que sea necesario explicar con más detalle. En todo caso, Lepe, gracias por la información, puesto que nada más sencillo que valerse uno del "JclDebug" (al menos para ciertas cosas, porque no es poco potente, a lo que se ve), sin olvidar el trabajo que les ha tenido que llevar a sus programadores el preparar algo así, claro está. Última edición por dec fecha: 06-10-2005 a las 02:50:07. Razón: Corrección del texto. |
|
#2
|
||||
|
||||
|
Como en este hilo se daba información general, eso mismo hice yo.
Para el caso de jclDebug, ha de tenerse en cuenta 2 cosas: - Hay que incluir en el primer formulario o Datamodule que crees el uses jclDebug, ya que realiza una inicialización en su unidad para empezar el "traceo" de excepciones. - En la distribución de tu ejecutable, tienes que distribuir un archivo .map que se crea al compilar, (abrelo con el bloc de notas para saber de que hablo). En este caso se tiene que distribuir un par de megas más, pero perece la pena. - Además de la información de jclDebug, se debe incluir las ventanas abiertas en tu aplicación (si son varias) para saber lo que hacia el usuario, (el objeto TScreen vale para eso). -En cuanto al uso de compresores de ejecutables, acabo de probarlo, y efectivamente el compresor elimina la información de debug, por lo que interfiere con JCLDEBUG, como ya sabemos: no se puede tener todo . Para el primer punto, yo me he construido mi propia jclDebug, que unicamente cambia los procedimientos por funciones y devuelve el error en una variable. Os lo dejo aqui: (El nombre de la unidad lleva el prefijo LP (Lepe) para que no interfiera con posibles modificaciones de la JCL) Saludos
saludos |
|
#3
|
||||
|
||||
|
Hola,
Cita:
Gracias Lepe por la información, en todo caso. |
|
#4
|
|||
|
|||
|
donde consigo los componentes
estoy buscandolos pero hasta ahora no los encuentro ..
y la ultima Lepe: a que te refieres con lo de las ventanas abiertas ? GRACIAS por tu ayuda Ingel |
|
#5
|
||||
|
||||
|
Hola,
Cita:
|
|
#6
|
||||
|
||||
|
Si tu programa tiene 60 o 70 ventanas y se produce una excepción del tipo '' is not a valid date... ¿En cual de las 70 ventanas se ha producido el error?.
Podríamos averiguarlo por el nombre de la unidad (UnitName del mensaje), pero también nos dá más información de los hábitos de ese usuario, es decir, si tiene varias ventanas de nuestro programa abiertas al mismo tiempo, o si abre una ventana, modifica lo que sea y la cierra; según los hábitos de los usuarios, podemos agilizar la apertura y cierre de las ventanas u otros detalles de nuestra aplicación. El bucle sería algo así:
Ni que decir tiene que todo esto debe grabarse en un .txt o .log y al usuario solo indicarle que ha habido un error y se ha guardado la información de depuración. Para el .log, ya que instalas la JVCL, tienes el TjvLogfile en la pestaña "Jv Utils" En cuanto a las preguntas de dec no puedo asegurar nada. Soy consciente de que en el .exe van algunos datos de la JCLdebug, tal y como dice la ventana que aparece tras hacer un Build Project estando activo el "insert jcl debug data", en mi caso, dice que el archivo .map son 3 megas, y la información de debug incluida en el .exe son 414 kb. No me queda claro si va todo en el exe o no. Compilar sin información de debug y con información de debug si varía 400 kb en el tamaño del ejecutable. saludos saludos |
|
#7
|
||||
|
||||
|
Hola,
Gracias Lepe, por todo. ![]() |
![]() |
| Herramientas | Buscar en Tema |
| Desplegado | |
|
|
|