TTimer limit..

[Ian Branch 127]

Hi Team,

I just ran up against the limit of TTimer in 32bit.  4,294,967,295.  😞

I need to 'TTimer' to 15,000,000,000.

Why 15,000,000,000?  Because the Timer is being used to set an 8hour limit on the operation of an App.

No, I can't go to 64bit.  The Customer only has 32bit OS. 😞

Thoughts, suggestions appreciated.

Regards & TIA,

Ian

Edited September 6, 2022 by Ian Branch

[Mike Torrettinni 198]

Perhaps something like this:

Timer.Interval := 1000000000;//1,000,000,000
fIntervalCount := 0;

OnTimer
  Inc(fIntervalCount);
  if fIntervalCount >= 15 then
    ...

 

[Dave Nottage 557]

16 minutes ago, Ian Branch said:

Thoughts, suggestions appreciated.

I'm wondering what happens if your machine goes down or restarts during the timer interval.

[Ian Branch 127]

Hi Mike,

Thanks for the suggestion, I will see if that is practical.

The TTimer functionality is within an Idle Timeout component, I don't really want to mess with the internals if I can avoid it.

 

Ian

[Ian Branch 127]

So I was jus coming back to add that the TTimer is in an App Idle component.

It is a slightly modified version of the unit in ccLib by David Cornelius on GitHub.

It looks for keyboard and/or mouse activity and if it doesn't see any for the time out period, 8 hours (240min), then it closes the App.

Edited September 6, 2022 by Ian Branch

[Mike Torrettinni 198]

3 minutes ago, Ian Branch said:

So I was jus coming back to add that the TTimer is in an App Idle component.

It looks for keyboard and/or mouse activity and if it doesn't see any for the time out period, 8 hours (240min), then it closes the App.

Just wanted to say be careful with these numbers, if they are important... 8h = 480 minutes, right?

[Ian Branch 127]

OK.  I have got myself confused here.  😞

8 hours = 480 minutes = 28,800 secs = 28,800,000 microsecs.  (interval)

Hmmm.  Then the TTimer should be handling it correctly with a limit of 4,294,967,295.

OK.  I need to look elsewhere to find out why it isn't working at 8 hours.

Thank you all for your contributions, Apologies for any inconvenience.

 

Ian

 

P.S.  I just checked the actual in-App setting.  Yes, I had 480 minutes.

Edited September 6, 2022 by Ian Branch

[Ian Branch 127]

OK.  Just to put your minds at ease.

1.  I am getting too old for this stuff......

2.  The TTimer is only running to 60 secs, then it increments a minutes counter until the minutes counter reaches the Idle Minutes limit.

So.  It's not the timer, something else must be keeping the App 'Alive' even though the User isn't actually doing anything.

Back to the drawing board.

[Remy Lebeau 1393]

5 minutes ago, Ian Branch said:

OK.  I have got myself confused here.  😞

8 hours = 480 minutes = 28,800 secs = 28,800,000 microsecs.  (interval)

The TTmer interval is expressed in milliseconds, not microseconds.

5 minutes ago, Ian Branch said:

Hmmm.  Then the TTimer should be handling it correctly with a limit of 4,294,967,295.

Yes.  4,294,967,295 milliseconds is 49.7 days.

5 minutes ago, Ian Branch said:

OK.  I need to look elsewhere to find out why it isn't working at 8 hours.

What EXACTLY is not working for you?

[Ian Branch 127]

OK.  I have resolved this issue by hard coding an 8 hour time limit.  The App is a Dashboard that is displayed on a screen at the start of the day.  No user interaction required.

At the start of the App I note the date/Time.

There is a 60 second timer in the App doing something else.

I put a test at the start of the Timer's event to test "  if MinutesBetween(Now, dtStartDateTime) >= 480 then Close;"

That should resolve what  I believe is the underlying IdleTimer issue.

 

The App resides on a Win 2012 Server.  It is accessed and displayed in a Browser via the Web using Cybele's ThinFinity.

I suspect that something in the Browser-ThinFinity-Server sequence is causing the App and therefore the IdleTimer to believe that something, either a keyboard or mouse, action has occurred, thus resetting the IdleTimer.

[Angus Robertson 574]

A lot of my applications have what I call triggers, there is a single timer firing every few seconds, and within that are Int64 triggers set for the required internal and tested against GetTickCount64 or GetTickCount.  There is a small library of functions to set triggers for minutes or hours and check them. 

 

Angus

 

[David Heffernan 2345]

Using a GUI timer like this is likely wrong anyway. 

[Rollo62 536]

TTimer I would use only for moderate, small times, lime 100ms, 1sec, 30sec.  for sure much less than a day.

If you really need to monitor several days you better look after TStopwatch or even a simple TDateTime, which can easily check the elapsed time against an initially stored start-time.

When the start-time is implemented as persistent data and can can withstant app-re-start and OS re-boot, you are on a much safer side.

 

You might know: Time is the only really reliable, unique running counter ....

[Remy Lebeau 1393]

9 hours ago, David Heffernan said:

Using a GUI timer like this is likely wrong anyway. 

Agreed.

8 hours ago, Rollo62 said:

If you really need to monitor several days you better look after TStopwatch or even a simple TDateTime, which can easily check the elapsed time against an initially stored start-time.

When the start-time is implemented as persistent data and can can withstant app-re-start and OS re-boot, you are on a much safer side.

For lengthy periods, I would ask the OS to notify me when the desired time has been reached, rather than polling the time regularly.

[Fr0sT.Brutal 900]

On 9/7/2022 at 11:16 AM, Rollo62 said:

Time is the only really reliable, unique running counter

Provided you have your clocks correctly synced