Caveats of the TTimer - Suggestions?

[David S. Becker]

I have recently run into some sticky problems surrounding the manipulation
of VCL components from within a TTimer's OnTimer event. It seems that the
OnTimer event serves as an interrupt, halting normal processing of
messages until the event is over. This has caused me some strange
problems, too numerous to elaborate all of them...

I have an application which may have multiple forms open, and runs
automatic nightly maintenance at midnight, which is triggered by a timer.
The maintenance is a separate EXE, which causes problems because some of
the open forms on the main application have open databases associated with
them. Our solution was to recursively iterate through the components
property closing all child forms as they were encountered, thereby closing
the databases with them. But the forms did not close right away, and
would still be open when the maintenance tried to run.

After much testing, and talking with Borland support, I came to the
conclusion that there was a 'race' going on. By calling close, I was
causing messages to be queued up, but they would not be processed until
the OnTimer event finished (even if I put in Application.ProcessMessages)
-- a problem, since the separate EXE was also launched from the timer
event. The solution was to use two timers, one to close the windows and
turn on a second timer which would wait a second then call the EXE.
*THAT* worked. Apparently, by allowing the first timer event to exit, the
messages would be processed, the windows (and databases) would close, and
then when the second timer went off, we were clear to run our maintenance.
(Whew, hope that was intelligable!)

After continued 'playing' I have come to the conclusion that you cannot
rely on any interactions with the VCL to take place until AFTER the timer
has finished -- an undesirable situation in some cases. (Perhaps this is
much the same problem as threads in D2 and the need for the Synchronize
function?) So, how then, are we supposed to 'synchronize' timer events
with the VCL message queue so that we count on changes happening? Am I
making any sense here? All feedback desired!
--
David S. Becker
ADP Dealer Services (Plaza R&D)
mailto:d...@plaza.ds.adp.com
(503) 402-3236
--

ADP Dealer Services (Plaza R&D)
mailto:d...@plaza.ds.adp.com
(503) 402-3236

[Ray Lischner]

On 8 May 1996 15:27:58 GMT, David S. Becker <d...@plaza.ds.adp.com>
wrote:

>I have an application which may have multiple forms open, and runs
>automatic nightly maintenance at midnight, which is triggered by a timer.
>The maintenance is a separate EXE, which causes problems because some of
>the open forms on the main application have open databases associated with
>them. Our solution was to recursively iterate through the components
>property closing all child forms as they were encountered, thereby closing
>the databases with them. But the forms did not close right away, and
>would still be open when the maintenance tried to run.
>
>After much testing, and talking with Borland support, I came to the
>conclusion that there was a 'race' going on.

Exactly, but I don't think it has anything to do with timers, just the
normal world of multitasking (more or less).

The normal solution in a multitasking world is to use a semaphore. The
timer application waits on the semaphore, which is signaled after the
last database is shut down.

If you using Delphi 2, then you are in luck, since the Win32 API
support semaphores. In Delphi 1, you need to resort to tricks.

> The solution was to use two timers, one to close the windows and
>turn on a second timer which would wait a second then call the EXE.
>*THAT* worked. Apparently, by allowing the first timer event to exit, the
>messages would be processed, the windows (and databases) would close, and
>then when the second timer went off, we were clear to run our maintenance.

The race condition still exists. What if it takes longer than one
second to close the database files?

Frankly, I haven't thought very long or hard about creating semaphores
in Windows 3.1, but a simple lock file should do the trick. The timer
application polls for the existence of the file, and the database apps
create the file after all the databases have been properly closed.
--
Ray Lischner li...@tempest-sw.com
Tempest Software, Corvallis, Oregon, USA http://www.tempest-sw.com