View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004319 | JEDI VCL | 00 JVCL Components | public | 2007-12-18 06:03 | 2008-10-26 05:37 |
Reporter | ZENsan | Assigned To | AHUser | ||
Priority | normal | Severity | tweak | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Product Version | Daily / GIT | ||||
Target Version | Fixed in Version | 3.36 | |||
Summary | 0004319: TJvTimerThread incompatibility | ||||
Description | TTimer works in this way: You set Timer.Enabled := True; And then if interval is one minute - it runs only after minute. But TJvTimer runs immidietly when enabled is set to true. To solve this problem I suggest to move some part code below to top of loop. | ||||
Additional Information | JvTimer.pas [Line 181] if not ThreadClosed and not ThreadClosed and FOwner.FEnabled then begin if FOwner.SyncEvent then begin Synchronize(FOwner.Timer) end else begin try FOwner.Timer; except on E: Exception do begin FException := E; HandleException; end; end; end; end; {FOLLOWING BLOCK MUST BE FIRST!} {-----------------------------------------------------------} CurrentDuration := 0; while not ThreadClosed and (CurrentDuration < FInterval) do begin SleepEx(Step, False); Inc(CurrentDuration, Step); end; {-----------------------------------------------------------} | ||||
Tags | No tags attached. | ||||
|
This means that TJvTimer.Enabled method (SetEnabled) must NOT pause thread, but terminate (with wait if need).. And when when enabling - create thread again. Only then timer will work like good TTimer. |
|
I'm having a hard time understanding your note. Can you give me more details? |
|
Hello? Any comments? |
2008-07-25 02:45
|
Timers.zip (1,254 bytes) |
|
First button is CodeGears's TTimer - and the appeareance how it MUST work. But all Jedi timer works wrong when in Threaded mode. "{FOLLOWING BLOCK MUST BE FIRST!}" I suggested to change blocks, put delay in the beginning and execution after - as it must be. |
|
I agree with ZENsan, just moving that block to the start would make the code equivalent to TTimer. However, this will affect the functionallity of every single application that makes use of TThreadedTimer, as all developers using it already expect the event to happen when its status is set to true, not after 1,5 or 10 minutes later. I, for example, would have huge problems if that happenned in my apps, so I'd prefer that the code stays at it is, but add a note/comment around it informing of this difference to the TTimer behaviour. |
|
Maybe easier and better to add TJvTimerEventTime = (tetPre, tetPost) Where property EventTime will determine how event is called (precalling or postcalling) |
|
Ok, thanks for the comments. Issue available for anyone to look at, I quite like the idea of the enumeration indicating pre or post trigger |
|
Added property EventTime default tetPre |
Date Modified | Username | Field | Change |
---|---|---|---|
2007-12-18 06:03 | ZENsan | New Issue | |
2007-12-23 08:14 | ZENsan | Note Added: 0014093 | |
2008-02-20 09:17 | obones | Note Added: 0014184 | |
2008-02-20 09:17 | obones | Status | new => feedback |
2008-07-23 07:22 | obones | Note Added: 0014438 | |
2008-07-25 02:45 | ZENsan | File Added: Timers.zip | |
2008-07-25 02:48 | ZENsan | Note Added: 0014458 | |
2008-07-25 02:49 | ZENsan | Note Edited: 0014458 | |
2008-08-07 05:35 | anudedeus | Note Added: 0014476 | |
2008-08-07 05:43 | anudedeus | Note Edited: 0014476 | |
2008-08-07 06:50 | ZENsan | Note Added: 0014477 | |
2008-10-10 05:05 | obones | Note Added: 0014809 | |
2008-10-10 05:05 | obones | Status | feedback => acknowledged |
2008-10-26 05:35 | AHUser | Status | acknowledged => resolved |
2008-10-26 05:35 | AHUser | Fixed in Version | => Daily / SVN |
2008-10-26 05:35 | AHUser | Resolution | open => fixed |
2008-10-26 05:35 | AHUser | Assigned To | => AHUser |
2008-10-26 05:35 | AHUser | Note Added: 0014910 |