The Timer.OnExecute I mentioned being run inside the loop excludes some of
the functions that are normally executed by the timer, as these functions
can not execute while we are waiting on the thread.
The timer cannot be idle.  It's not just updating the UI but doing some
other important work that is necessary to continue.

I should probably mention that it's a media player with a VU meter that
needs updating continuously and elapsed/remaining times etc.  The other
thread is doing the actual playing of the audio files.

The wait needs to occur when sending a command to the thread to preload a
track, or start playing, etc.  On occasions, a procedure in the main app
involves issuing several commands which need to occur sequentially, hence
the need to wait until one command is complete.  Normally this wait is less
than 1 second, but it's still long enough at times to get a modal dialog
opened within the ProcessMessages loop, and then this function hangs.

It's been like this for years, but the occasional user comes across the
problem and the media player stops, generally between tracks, when opening a
modal dialog at the wrong moment.

Preventing a modal window from opening while in this loop seems to be the
only solution.  The messages I was trying to avoid processing were mouse
clicks and keyboard keys.

Any other ideas how to resolve this?


-----Original Message-----
From: [] On
Behalf Of Paul Heinz
Sent: Tuesday, 2 August 2011 4:04 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Why does this hang?

Hi Ross 

> I can't remember now what problem I was having with 
> Application.ProcessMessages but this code fixed it while I 
> was testing, and had to find tune the message numbers.  I 
> failed to comment the code.  I think it had something to do 
> with other visible non-modal forms.
> I may have to re-instate ProcessMessages and see what the problem was.
> The wait loop is generally no more than 2 or 3 seconds 
> waiting for a thread command to finish, but I need the main 
> window to update continuously during this time.

Hrmm.. I don't really understand the architecture of your app, but
_usually_ threads are an attempt to NOT have to have blocking busy-wait
loops in your main UI thrad. Could your worker thread not send a message
(or use Thread.Synchronise which sends a message for you) to signal it's
completion instead?

In short, why can't you just return to the normal message loop? 

It sounds like your application has some of behaviour mode that depends
on the thread completion state but that might be better handled in the
message event handlers themselves thus completely decoupled from the
message loop itself.

Finally, it's more of a side issue but the timers you speak off which
are updating the UI - are they able to be handled as idle time events
instead or are they actually indicating timing related information to
the user?


NZ Borland Developers Group - Delphi mailing list
Unsubscribe: send an email to with Subject:

NZ Borland Developers Group - Delphi mailing list
Unsubscribe: send an email to with Subject: 

Reply via email to