TTimer elapsed do not runs asociated event... sometimes

[Mike.Cornflake]

Fair enough.  Hopefully you can make some progress with reducing this to a reproducible test case so we can all see what's going on.

Good luck.

[engkin]

Because the server thread does not process WM_TIMER, only the GUI thread does.

Edit:
Only the default window procedure calls the callback function for the timer.

[Mike.Cornflake]

Because the server thread does not process WM_TIMER, only the GUI thread does.

Edit:
Only the default window procedure calls the callback function for the timer.

Good catch.  I missed that in your earlier post.   What's the solution then?  Implement his own wndproc and listen for WM_TIMER (via the methods below)?
 
http://lazarus-ccr.sourceforge.net/docs/lcl/controls/twincontrol.wndproc.html
http://wiki.lazarus.freepascal.org/Win32/64_Interface#Processing_non-user_messages_in_your_window

[taazz]

Because the server thread does not process WM_TIMER, only the GUI thread does.

Edit:
Only the default window procedure calls the callback function for the timer.

Good catch.  I missed that in your earlier post.   What's the solution then?  Implement his own wndproc and listen for WM_TIMER (via the methods below)?
 
http://lazarus-ccr.sourceforge.net/docs/lcl/controls/twincontrol.wndproc.html
http://wiki.lazarus.freepascal.org/Win32/64_Interface#Processing_non-user_messages_in_your_window

I guess if this assumption is correct, which I don't know what to believe because the event sometimes fires and with this assumption it should never fire, then a thread based timer would be a better solution to this problem, since there is no message for the fired event but a direct call, or something along those lines.

[engkin]

I hate the "remove" link. 
----
I agree with Taazz: "a thread based timer".
----
Edit:
I .... never mind.

[Mike.Cornflake]

I hate the "remove" link. 
----
I agree with Taazz: "a thread based timer".
----
Edit:
I .... never mind.

Tried to modify your post, deleted it instead?   Been there, done that

[User137]

There are two conditions:

Code: [Select]

procedure TCustomTimer.Timer;
begin
...
  if (FEnabled) and (FInterval > 0) then
    DoOnTimer;
end;

Enable is true and Interval > 0.

Huh, why does Interval have to be > 0? It has always worked just fine with Interval 0 on Delphi at least.

[Mike.Cornflake]

Huh, why does Interval have to be > 0? It has always worked just fine with Interval 0 on Delphi at least.

Really?  How often does it run?

Oh.  According to the online docs our implementation is the same as Delphi
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/delphivclwin32/ExtCtrls_TTimer_Interval.html

Note: A 0 value is valid, however the timer will not call an OnTimer event for a value of 0

[Scoops]

I'm probabaly off topic cos its late here. When i last used delphi it is was not advised
to use threads for anything in a gui enviroment, procedures ok but nothing visual.
I say delphi cos it was mentioned earlier. And lazarus tries to be compatible with delphi.
And anything under 50ms doesnt change anything (as far as windows is concerned).
as for linux etc i dont know, but windows its 50ms minimum.

[taazz]

I'm probabaly off topic cos its late here. When i last used delphi it is was not advised
to use threads for anything in a gui enviroment, procedures ok but nothing visual.
I say delphi cos it was mentioned earlier. And lazarus tries to be compatible with delphi.

that is still true today on delphi and lazarus.
 

And anything under 50ms doesnt change anything (as far as windows is concerned).
as for linux etc i dont know, but windows its 50ms minimum.

well there was never such a high threshold on winNT based systems ee nt3.1 2000, xp etc I have no recollections for win 95/98 and the rest I'm sorry to say so, but even then it is the CPU that specifies the threshold if we are talking about the same thing it was around 25MS in the win2000 era and it is around 16MS in todays CPUs with the multiple cores and all that.
Care to post any reference?

[torbente]

Because the server thread does not process WM_TIMER, only the GUI thread does.

Edit:
Only the default window procedure calls the callback function for the timer.

Good catch.  I missed that in your earlier post.   What's the solution then?  Implement his own wndproc and listen for WM_TIMER (via the methods below)?
 
http://lazarus-ccr.sourceforge.net/docs/lcl/controls/twincontrol.wndproc.html
http://wiki.lazarus.freepascal.org/Win32/64_Interface#Processing_non-user_messages_in_your_window

I guess if this assumption is correct, which I don't know what to believe because the event sometimes fires and with this assumption it should never fire, then a thread based timer would be a better solution to this problem, since there is no message for the fired event but a direct call, or something along those lines.

Because the server thread does not process WM_TIMER, only the GUI thread does.

Edit:
Only the default window procedure calls the callback function for the timer.

The Timer works perfect ALWAYS when i make click in the button. If the server receives a order to run the same procedure like if you click the button, it ALWAYS fails.

I guess engkin is right; there are more timers in the form, i will check all them to see if they all have the same result (as i can remember now, only one timer is modified via code from the server anyway)

Are there any workaround if this is the case? The server must be automatic to process all request.

Also, if a timer is already enabled and a Timer.Enabled:= true is called, the interval is supossed to restart?

[engkin]

Are there any workaround if this is the case? The server must be automatic to process all request.

Use WaitForSingleObject. For a nice example, check the first answer on this stackoverflow link

I came across this Timer that seems to be another possible solution.

Also, if a timer is already enabled and a Timer.Enabled:= true is called, the interval is supossed to restart?

No, according to the source code:

Code: [Select]

procedure TCustomTimer.SetEnabled (value : boolean);
begin
  if (Value <> FEnabled) then
  begin
    FEnabled := value;
    UpdateTimer;
  end;
end;
The new value has to be different to cause any change.

Edit:
Corrected the method. Thanks Taazz.

@Mike.Cornflake, thank you. I fell for this mistake twice, deleting my posts instead of modifying them. This time it did upset me enough to modify a browser extension to remove the Delete Button.

[taazz]

No, according to the source code:

Code: [Select]

procedure TCustomTimer.SetInterval (value : cardinal);
begin
  if (value <> FInterval) then
  begin
    FInterval := value;
    UpdateTimer;
  end;
end;
The new value has to be different to cause any change.

Correct answer wrong method quoted.

[torbente]

Well, thanks to all who show interest on this topic. I was able to solve it with a simple workaround: I just added a new variable which is switched true/false by the client. Depending on this new variable, the asociated event to the Timer is executed or not. Finally, the timer is never disabled. I guess this is the easy solution for situations like this.