FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
Mostrar ventana con cuaderno de bitácora en programa automático
Pues estaba yo codificando y me he dado cuenta de un detalle tonto.
Tengo que hacer un programa que funciona solo. Se le mete en el "programador de eventos" para que se ejecute, por ejemplo, cada 24h y él trabaja solito y cuando termina su tarea pues se cierra y hasta la siguiente. Se me ocurrió que, en lugar de ser silencioso, abriera una ventana principal con TMemo de sólo lectura en el que fuera escribiendo qué es lo que va haciendo y, cuando termine, que lo vuelque todo en un archivo de texto a modo de cuaderno de bitácora (log). Si se produce un error durante la ejecución, el programa no se cierra y así se puede ver cuándo ha fallado y qué es lo que estaba haciendo cuando se rompió. Hasta aquí todo bien. Ahora viene lo gordo. Estoy utilizando el evento OnCreate para inicializar el programa, pero no sé como "comenzar el trabajo". Por ahora he hecho algo así como: Pero claro, no me parece muy correcto y aunque por ahora funciona tal vez me de problemas más adelante. También había pensado en quitar el "Show" y el "RealizaTrabajo" de este evento y ponerlas en el evento "onShow", pero tampoco. Como el trabajo (por ahora) es muy corto el progama termina casi antes de mostrar la ventana, en ambos casos, así que no sé si lo hace bien o no. Se me había ocurrido hacerlo todo en el módulo principal (el archivo "dpr"). Ahora este archivo es así: Y yo querría hacer algo así como: Evidentemente eliminaría todo el código de los eventos de la ventana. Sin embargo, eso de quitar el "Application.Run" no termina de gustarme, y si lo pongo no me ejecutará el resto, ¿o sí? ¿Me arriesgo o alguien conoce una forma mejor de hacerlo? Última edición por Ñuño Martínez fecha: 19-01-2007 a las 14:25:29. Razón: El título está mal puesto. |
#2
|
||||
|
||||
Se me ocurren varias posibilidades, la primera es hacer una aplicación de consola, con sus writeln , me parece que se ajusta bastante bien a lo que quieres. Es mas, nada te impide utilizar en la misma aplicación la consola y ventanas, por si mas adelante en tu aplicación necesitas ventanas.
Si la idea de la consola no te gusta, podemos recurrir a los mensajes. En el evento OnCreate posteamos un mensaje, y cuando lo recibamos la ventana ya se estará mostrando. Algo así:
|
#3
|
||||
|
||||
Hola,
La verdad, no pillo el problema o la dificultad que tienes. Pero si dices Cita:
Ahora me explico: Cita:
Bien, no me parece buena idea lo de guardar el log al final de la ejecución, sino siempre que añadas algo. Así tengo una función, a la que le pasas como parámetro el texto que quieres guardar (como muy bien has hecho tú tambien), y esta función abre el fichero de log, inserta esa linea, junto con la fecha y hora del sistema (usando formatdatetime para una mejor lectura), y graba el fichero. Es un fichero de texto y su acceso, como sabes, es muy rápido, y los programas no relentizan nada. Lo digo, porque así siempre tendrás el fichero con el log actualizado, si lo guardas en un memo, por ejemplo y al final lo guardas, te arriesgas a que por cualquier cosa, se cierre de mala manera (KillTask, apagón, etc) y pierdes el log; sabrás que ha ido mal y no tendrás el log para averiguarlo. Además de esta manera, no necesitas visualizar una ventana con el log, si es allí donde tienes los problemas. Como comentario al código que has puesto, sólo decirte que no parece buena idea, mostrar la ventana que deseas en el OnCreate de la aplicación u OnShow, sino mostrarlo cuando la aplicación esté activa, es decir, en el OnActivate. Bueno ya me comentas si te he entendido, si me explicas que ocurre y seguimos conversando y si te sirve de ayuda mi experiencia previa. Saludos |
#4
|
||||
|
||||
Como dijo nuestro querido Jack, "vayamos por partes":
Cita:
Cita:
Decididamente lo haré por consola y guardando en el archivo línea a línea, en lugar de usar el TMemo. Por cierto, para hacer la configuración voy a tener que mostrar una ventana. ¿Servirá algo así?
Evidentemente, "Acepta" es una propiedad de la ventana que se pone a TRUE al pulsar el botón aceptar. |
#5
|
||||
|
||||
Cita:
Personalmente opino, (y quizá sea una tontería), pero si es una aplicación que no tiene que verse, no muestre ninguna ventana incluso para la configuración. Pero OJO: a configuración entiendo, como parámetros de la aplicación y no como un filtro de datos. En pocas palabras un fichero .INI Para ello, si estoy empezando a optar (en caso de aplicaciones "invisibles"), que la configuración se haga desde otro programa. Y tú aplicación de consola, abre el INI y guarda los valores en variables. Pero, oye, es mi opinión Saludos |
#6
|
|||
|
|||
Yo cambiaría esta parte
por esto
al hacer el ShowModal ya se para la ejecución hasta que se haga el ModalResult del formulario |
#7
|
||||
|
||||
Gracias Bicho, por sugerir lo de utilizar dos programas (uno para configurar y el otro que haga el trabajo), al final va a ser lo más cómodo.
Y gracias fdelamo por corregirme lo del "ShowModal". Olvidé que las ventanas "modales" devuelven el "ModalResult" cuando se cierran. Estoy de un olvidadizo subido... |
#8
|
||||
|
||||
Bueno, yo sigo dandole vueltas al asunto
Se me ocurre tener 2 aplicaciones, una es el propio programa y la otra vigila a la primera. El vigilante seria una aplicación como esta:
Ahora en la aplicación principal usaríamos un procedure tal como este:
De esta manera, si iniciamos la aplicación principal solamente, el procedure no tendrá ningún efecto. Sin embargo, si la ejecutamos desde la aplicación bitácora, esta mostrara los mensajes. Por ejemplo: Código:
Bitacora.exe Principal.exe /Algunparametro |
#9
|
||||
|
||||
¡Corcho! Hoy ya no me da tiempo a mirarlo con detenimiento, pero lo haré el lunes sin falta.
seoane, ¿tú no trabajas ni tienes una carrera pendiente ni nada? |
#10
|
||||
|
||||
Cita:
|
#11
|
||||
|
||||
Ya está el agonioso que todo lo sabe escribiendo código, otra vez
Pero Domingo, éste es un foro de habla hispana, ¿podrias repetir tu propuesta en castellano, para que te entendamos los demás? Por que yo me he quedado igual que si no lo hubiera visto... Saludos |
#12
|
||||
|
||||
Pues después de leerme el código fuente (no lo he probado) puedo decir que sí: es matar moscas a cañonazos...
|
#13
|
||||
|
||||
Cita:
Ya dije que podía ser excesivo, pero hay que reconocer que usar las propias salidas estándar es una solución muy elegante. |
#14
|
||||
|
||||
Cita:
|
#15
|
||||
|
||||
Cita:
Controlándolo desde otro programa podremos obtener mas datos, que desde el mismo programa. Incluso en caso de error grave podemos realizar alguna acción: ejecutar el programa de nuevo, enviar un reporte, acordarnos de la madre del usuario ... |
#16
|
|||
|
|||
Cita:
Que ventajas tiene usarlo? O sea me refiero a: Application.ProcessMessages; TMessage Saludos y desde ya muchas gracias |
#17
|
||||
|
||||
Cita:
Ahora, el código que pusiste más arriba imagino que es para redireccionar la entrada y salida estandar para que el programa vigilante lea lo que el programa principal escribe en la consola. Pero, el programa principal ¿no podría mejor usar un memory mapped file para pasar información al otro? Mmmm.. Aunque de la manera que planteas, el programa principal igual saca sus mensajes aun en la eventualidad de no tener vigilante. Pues viéndolo así, no me parece un cañonazo. Es decir, que me parece una opción muy adecuada. // Saludos Última edición por roman fecha: 23-01-2007 a las 00:06:20. |
#18
|
||||
|
||||
Cita:
Voy a tener que guardar el cañón ... |
#19
|
||||
|
||||
Puedes poner un meta-vigilante que levante al vigilante. Y ya entrados en gastos, un meta-meta-vigilante que levante al meta-vigilante, aunque sería más seguro si agregases un meta-meta-meta-vigilante que levante al meta-meta-vigilante
Es nada más por fastidiar , repito que me parece que el método que explicaste es muy buena opción. // Saludos |
#20
|
||||
|
||||
Pues roman, es una de las ideas que me ronda la cabeza cuando estoy aburrido, como hacer, sin meternos en temas de permisos y demás, que una aplicación no se pueda cerrar. La idea, y ya estoy sacando el cañón , es hacer dos programas que se vigilen mutuamente, así cuando uno cae el otro lo vuelve a levantar, se vigilan las espaladas el uno al otro.
Pero nada, sera mejor que vuelva a guardar el cañón, y que cada programa se escriba sus propios logs y en casos mas complicados usar OutputDebugString que para eso esta. |
|
|
|