Stefan,

You can create your own function that would take into account date change and use it instead of SECONDS(). For example

? mySECONDS(), SECONDS()
...
FUNCTION mySeconds(tdBase)
LOCAL ldBase
ldBase = IIF(EMPTY(tdBase), {^2003/01/01}, tdBase)
RETURN (DATE() - ldBase) * 86640 + SECONDS()

>No, I'm not using a Timer control because it wouldn't work. Timer controls are for when the computer is idle and wondering what to do. What I'm doing is deciding when to update visuals when the computer is running full load, similar to SET ODOMETER or the way form control repainting is b0rken in VFP (i.e. in certain contexts VFP repaints only when it feels like it and ignores refreshes that are more frequent).
>
>Basically, the processing code transfers control to the feedback class by invoking a LoopEvent method at some appropriate looping level that has higher frequency than the desired visual update frequency. The feedback class keeps track of the time and when the configured update interval (say, 100 ms) has elapsed or some other update condition is triggered then it updates the visuals - status bar via SET MESSAGE, a form by invoking a method, whatever. It can also query the input status and react accordingly, all without impacting the performance of the processing code because the overhead of the LoopEvent method is very small (about 0.01 ms per call on my notebook) and the expensive code gets executed only at the configured rate.
>
>I have found a frame rate of 10..15 fps to give a good balance. It is fast enough to give a good visual impression of the rate of change but is still slow enough not to impact processing performance noticably.
>
>The basic logic for a simple context would be like so:
>
<snip>>
>SECONDS() is perfect for the update interval job but without the help of DATETIME() there is a hard limit of 24 hours with regard to measuring elapsed process time (for benchmarking). Of course, mixing in DATETIME() makes the code more complex.