Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > Varios
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Grupo de Teaming del ClubDelphi

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 09-05-2007
molinero1 molinero1 is offline
Miembro
 
Registrado: abr 2007
Posts: 59
Poder: 17
molinero1 Va por buen camino
Application.ProcessMessages y Application.HandleMessages

Me podrían explicar como utlizar Application.ProcessMessages y Application.HandleMessages para poner un sleep en segundo plano? Muchas gracias.
Responder Con Cita
  #2  
Antiguo 09-05-2007
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.107
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

Podemos intentar explicártelo en la medida de nuestras posibilidades, pero, ¿podrías tú explicar qué entiendes por "poner un sleep en segundo plano"?
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
  #3  
Antiguo 09-05-2007
molinero1 molinero1 is offline
Miembro
 
Registrado: abr 2007
Posts: 59
Poder: 17
molinero1 Va por buen camino
Dec, felicidades por los 6000 mensajes. En primer lugar, creo que cuando se hace un sleep, el programa se queda como colgado, no puedes ver el programa si lo tienes por ejemplo minimizado. En segundo plano, me refiero a poder utilizar el programa, sin que se quede colgado.
Responder Con Cita
  #4  
Antiguo 09-05-2007
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.107
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

Muchas gracias, hombre. Tu aplicación tiene un Hilo de ejecución "principal". El uso de "sleep" hace que se detenga el Hilo de ejecución de la aplicación. Lo mismo ocurriría mientras se estuviera un "bucle while" más o menos intrincado y complejo. En este último caso se podría hacer algo... precisamente con una instrucción "Applicacion.ProcessMessages" dentro del bucle... pero... en el caso del "Sleep"... me temo que esto no sea posible.

Pero es que hay que ver el uso de "Sleep". Un "Sleep" no es un bucle. No creo que sea habitual "Sleeps" de más de un par de segundos... al menos yo no he visto algo así. De modo que tal vez te convenga tirar por otro lado, tratar de encontrar otra solución, que no sea el uso de "Sleep" y que te solucione lo que necesitas. Existe algo como los "Hilos" secundarios, por ejemplo, puedes usar la clase "TThread" de Delphi para implementar más o menos sencillamente un segundo Hilo (aparte del principal) en tu aplicación.

Tal vez por ahí vayan los tiros... pero, yo creo que tal vez podrías explicar un poco qué quieres hacer y tal vez alguien podría echarte una mano dándote alguna que otra idea. Pero... probablemente tengas que olvidarte del "Sleep" porque no se justifique su uso. Al menos es lo que pienso a bote pronto.
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
  #5  
Antiguo 09-05-2007
molinero1 molinero1 is offline
Miembro
 
Registrado: abr 2007
Posts: 59
Poder: 17
molinero1 Va por buen camino
Tengo un procedure, que quiero que se llame a si mismo, pero por ejemplo cada media hora, y luego en un for, quiero que haga una instrucción, cada tres minutos.
Responder Con Cita
  #6  
Antiguo 09-05-2007
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.107
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

Estupendo. Por lo que dices creo que lo que estás necesitando es un "TTimer". Un "TTimer" es un cronómetro (que corre en segundo plano respecto del Hilo principal de tu aplicación, y que por lo tanto no atrapará a este), digo, es un cronómetro que cuenta con un evento "OnTimer".

Tienes el "TTimer" en la pestaña "System" de la paleta de componentes de Delphi. Asignas un intervalo de 1800000 milisegundos (30*60*1000) a la propiedad "Interval" del "TTimer"... "True" a su propiedad "Enabled"... y tendrás que cada 30 minutos se disparará el evento "OnTimer" del "TTimer".

El "TTimer", como queda dicho, no ocupará el Hilo principal de tu aplicación. Ahora bien, cuando lleguemos al evento "OnInterval"... si ahí se ha de ejecutar un bucle "for" o "while"... tal vez entonces sea bueno contar con un "Application.ProcessMessages", dentro del bucle, empero, en todo caso creo que el problema se habrá reducido no poco, tal vez incluso eliminado del todo.

En todo caso: olvídate del "Sleep". Si quieres hacer "algo" cada cierto intervalo de tiempo el componente "TTimer" es lo que andas buscando.

PD. Adjunto un sencillo ejemplo de "reloj" que utiliza un "TTimer" para mantener actualizada la hora.
Archivos Adjuntos
Tipo de Archivo: zip Reloj.zip (1,9 KB, 65 visitas)
__________________
David Esperalta
www.decsoftutils.com

Última edición por dec fecha: 09-05-2007 a las 14:22:50.
Responder Con Cita
  #7  
Antiguo 09-05-2007
molinero1 molinero1 is offline
Miembro
 
Registrado: abr 2007
Posts: 59
Poder: 17
molinero1 Va por buen camino
Lo he provado y mas o menos me sale, pero me surgen dos dudas, Application.ProcessMessages que hace exactamente y donde lo tengo que poner? y en el evento on timer puedo llamar a un procedimiento creado por mi?
Responder Con Cita
  #8  
Antiguo 09-05-2007
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.107
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

Cita:
Application.ProcessMessages que hace exactamente y donde lo tengo que poner?
Básicamente, el método "ProcessMessages" de la clase "Application", fuerza el proceso de los mensajes del sistema que la aplicación tenga "encolados", es decir, aquellos que están pendientes de ser procesados. Este es el método "ProcessMessages":

Código Delphi [-]
procedure TApplication.ProcessMessages;
var
  Msg: TMsg;
begin
  while ProcessMessage(Msg) do {loop};
end;

Algunos bucles pueden "apoderarse" del Hilo principal de la aplicación, de modo que impiden que se procesen los mensajes del sistema que la aplicación debe procesar. Pues bien, el método "ProcessMessages", como se ve, fuerza a que la aplicación procese los mensajes pendientes... y luego regresa el control a quien llamara al método "ProcessMessages", ni más... ni menos.

Es una explicación acaso muy básica y hasta simple, pero, ahora mismo no se me ocurre otra, tal vez porque ni a mí mismo me quedan claras ciertas cosas, tal vez porque no quiera liar el asunto demasiado.

¿Dónde tienes que poner el "Application.ProcessMessages"? Pues básicamente donde veas que la aplicación se atore... y esto tiene lugar, por ejemplo, en algunos "bucles más o menos pesados". Dentro de estos bucles, pues, además del código que queramos ejecutar, puede y aun debe situarse un "ProcessMessages" para que la aplicación procese los mensajes encolados antes de seguir con la ejecución del bucle... o a cada ciclo de su éjecución.

Cita:
y en el evento on timer puedo llamar a un procedimiento creado por mi?
Por supuesto. Y no sólo eso, sino que el "TTimer" se ejecuta en un Hilo diferente del principal de la aplicación. Y esto quiere decir que ambos Hilos se ejecutarán "en pararelo", sin que el Hilo del "TTimer" impida la ejecución del Hilo principal de la aplicación. Puedes verlo en el ejemplo del reloj que he adjuntado antes: el reloj se actualiza cada segundo y el "label" correspondiente muestra la hora actualizada a cada segundo... sin problemas.

En todo caso me veo incapaz de dar muchas más explicaciones sobre estos temas... creo que aquí tendría que venir algún compañero de estos que tenemos por aquí que nos pueden dar sopas con ondas, como suele decirse, en esto de los "Hilos", "Timers", "Mensajes", etc., etc., etc.

En todo caso, si quieres ir un poco más allá, para empezar te recomiendo la ayuda del propio Delphi. Echa un vistazo a la ayuda del método "ProcessMessages" de la clase "Application". Lee su descripción y echa un vistazo al ejemplo que se ofrece. Y puedes seguir tirando del Hilo a partir de ahí...
__________________
David Esperalta
www.decsoftutils.com

Última edición por dec fecha: 09-05-2007 a las 14:48:06.
Responder Con Cita
  #9  
Antiguo 09-05-2007
molinero1 molinero1 is offline
Miembro
 
Registrado: abr 2007
Posts: 59
Poder: 17
molinero1 Va por buen camino
Thumbs up

Vale, muchas gracias, ya me funciona como yo quería y gracias a tu explicación la próxima vez que intente algo igual supongo que me las arreglare mas solo. Es mejor entender algo que copiar código solo porque si, al menos es lo que pienso, gracias otra vez .
Responder Con Cita
  #10  
Antiguo 09-05-2007
Avatar de seoane
[seoane] seoane is offline
Miembro Premium
 
Registrado: feb 2004
Ubicación: A Coruña, España
Posts: 3.717
Poder: 24
seoane Va por buen camino
Cita:
Empezado por dec
Por supuesto. Y no sólo eso, sino que el "TTimer" se ejecuta en un Hilo diferente del principal de la aplicación.
Ahí te has pasado Hasta donde yo se, los eventos del TTimer, al igual de los de la mayoría de componentes, se ejecutan dentro del hilo principal de la aplicación. Es mas, si estas dentro de un bucle y no utilizas Processmessages nunca ocurrirá el evento OnTimer.
Responder Con Cita
  #11  
Antiguo 09-05-2007
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.107
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

Bueno. Es probable que me equivoque, porque voy bastante perdido en estos menesteres, pero, yo no me refería tanto al evento "OnTimer" como tal (pero de todas formas haces bien en remarcarlo), sino a que el propio "Timer", es decir, "hasta que llegamos al evento OnTimer", debe haber un segundo Hilo que se ejecute en paralelo al nuestro, y que, precisamente, controle cuándo ha de ejecutarse el evento "OnTimer"...

Lo que pasa es que echando un vistazo he visto que el "TTimer" no utiliza un "TThread", sino que hace uso de las funciones "KillerTimer" y "SetTimer" del API de Windows... y ahí sí que ya no he seguido adelante para comprobar qué se supone que hace exactamente "SetTimer", puesto que entiendo que inicia un segundo Hilo en la aplicación...

Pero, vamos, que, de todas formas, ya digo... es muy probable que me equivoque porque estos temas me superan, así como suena.
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
  #12  
Antiguo 09-05-2007
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.107
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

Pero llevas razón de todas, todas Seoane:

Cita:
Empezado por Ayuda de la función SetTimer
An application can process WM_TIMER messages by including a WM_TIMER case statement in the window procedure or by specifying a TimerProc callback function when creating the timer. When you specify a TimerProc callback function, the DispatchMessage function simply calls the callback function instead of the window procedure. Therefore, you need to dispatch messages in the calling thread, even when you use TimerProc instead of processing WM_TIMER.
Pero no me queda claro si tengo algo de razón... es decir, si "SetTimer" crea un "Hilo" o algo parecido... porque al cabo ha de controlar cuándo ha de ejecutar el "TimeProc" de marras... ¿no?
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
  #13  
Antiguo 09-05-2007
Avatar de seoane
[seoane] seoane is offline
Miembro Premium
 
Registrado: feb 2004
Ubicación: A Coruña, España
Posts: 3.717
Poder: 24
seoane Va por buen camino
Efectivamente el TTimer hace uso de la función SetTimer. Esta API lo que hace es enviar el mensaje WM_TIMER a la aplicación cuando se cumple el tiempo indicado. Es el propio sistema operativo el que se encarga de "generar" ese evento, por lo que no hay necesidad de crear otro Thread. También, precisamente porque usa el mensaje WM_TIMER, es necesario que la aplicación procese los mensajes para que el evento del timer se produzca.

Una cosa curiosa, aunque la función SetTimer permite pasar una función como parámetro de tal forma que esta se ejecute al cumplirse el tiempo indicado, sigue siendo necesario el uso de un bucle de mensajes ya que es al procesar el mensaje WM_TIMER cuando se llama a esa función. Esto que parece una tontería, no lo es , porque si, por ejemplo, estamos creando una aplicación de consola que, en principio, no tiene bucle de mensajes y queremos usar un timer no nos queda mas remedio que crear nosotros mismos un bucle que procese los mensajes.

Ya llego de rollo por hoy ...
Responder Con Cita
  #14  
Antiguo 09-05-2007
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.107
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

Oh, no, nada de rollo. Las explicaciones razonadas nunca están demás Seoane y yo las agradezco.
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
InternetExplorer.Application altp .NET 0 08-11-2006 21:39:02
¿Application.MessageBox? Ledian_Fdez Varios 8 23-10-2006 23:19:44
Problema con Application.ProcessMessages Coco API de Windows 0 25-02-2005 16:28:44
No funciona Application.ProcessMessages Sr_Sombrero Varios 0 24-01-2005 23:21:01
Web Application LILYBEL Internet 3 21-10-2004 16:18:10


La franja horaria es GMT +2. Ahora son las 22:58:23.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi