On Sat, 7 Sep 2019, Zoe Peterson wrote:
From: Martin Frb
But that does not mean, it needs to be changed on existing targets.
And if it is not going to be changed, then it can be documented.
I agree with everything Martin has said, though IMO GetTickCount must
return values in ms on every s
On 08.09.2019 10:09, Michael Van Canneyt wrote:
On Sat, 7 Sep 2019, Zoe Peterson wrote:
From: Martin Frb
But that does not mean, it needs to be changed on existing targets.
And if it is not going to be changed, then it can be documented.
I agree with everything Martin has said, though IMO
On Sun, 8 Sep 2019, Yuriy Sydorov wrote:
On 08.09.2019 10:09, Michael Van Canneyt wrote:
On Sat, 7 Sep 2019, Zoe Peterson wrote:
From: Martin Frb
But that does not mean, it needs to be changed on existing targets.
And if it is not going to be changed, then it can be documented.
I agree
On 08.09.2019 13:42, Michael Van Canneyt wrote:
On Sun, 8 Sep 2019, Yuriy Sydorov wrote:
Strictly defined measurement units are important for cross-platform (and Delphi) compatibility. So GetTickCount_2 -
GetTickCount_1 must return how many milliseconds have elapsed between calls of GetTickCo
El 8/9/19 a les 13:17, Yuriy Sydorov ha escrit:
if GetTickCount - FStartTime > 3000 then ;
I actually use
if DWORD(GetTickCount-FStartTime) > 3000 then
the former is affected by the rollback after 49 days, the latter isn't.
vs
if Now - FStartTime > 3/SecsPerDay then ;
Besides, Now c
Am 08.09.2019 um 13:17 schrieb Yuriy Sydorov:
> Sure, measurements using GetTickCount is not precise (+-20ms on Windows).
On any reasonably recent kernel, it has 16ms granularity and even before that
was always guaranteed to be a monotonically incrementing (except for the
rollover) number of millis
On Sun, 8 Sep 2019, Luca Olivetti wrote:
El 8/9/19 a les 13:17, Yuriy Sydorov ha escrit:
if GetTickCount - FStartTime > 3000 then ;
I actually use
if DWORD(GetTickCount-FStartTime) > 3000 then
the former is affected by the rollback after 49 days, the latter isn't.
vs
if Now - FSta
On Sun, 8 Sep 2019, Martok wrote:
Am 08.09.2019 um 13:17 schrieb Yuriy Sydorov:
Sure, measurements using GetTickCount is not precise (+-20ms on Windows).
On any reasonably recent kernel, it has 16ms granularity and even before that
was always guaranteed to be a monotonically incrementing (ex
El 8/9/19 a les 18:23, Michael Van Canneyt ha escrit:
Besides, Now could go backwards (if system time is adjusted), while
GetTickCount cannot
It can if the fallback is used.
Well, that's a bug then.
Bye
--
Luca
___
fpc-pascal maillist - fpc-p
On Sun, 8 Sep 2019, Luca Olivetti wrote:
El 8/9/19 a les 18:23, Michael Van Canneyt ha escrit:
Besides, Now could go backwards (if system time is adjusted), while
GetTickCount cannot
It can if the fallback is used.
Well, that's a bug then.
It's the best you can do in absence of an ac
El 8/9/19 a les 19:08, Michael Van Canneyt ha escrit:
On Sun, 8 Sep 2019, Luca Olivetti wrote:
El 8/9/19 a les 18:23, Michael Van Canneyt ha escrit:
Besides, Now could go backwards (if system time is adjusted), while
GetTickCount cannot
It can if the fallback is used.
Well, that's a b
> If you're going to be insulting and personal, you might consider
> unsubscribing yourself from the mailing list: this is a technical
> discussion mailing list, not a tabloid where such things are permissible.
Oh, given that I've been called various things worse than a simple "that's not
how thi
On 08/09/2019 1:07 am, Alexander Grotewohl wrote:
> every call to gettickcount is something
> like 10-15ms or so off.
Martin's suggested documentation "The minimum resolution may vary"
makes that very clear.
Also anybody that works with timing API's should know that each platform
has differ
On 07/09/2019 8:42 pm, Zoe Peterson wrote:
> GetTickCount and GetTickCount64 are Windows API functions that are
> explicitly documented as returning milliseconds,
I have to agree with you. If FPC keeps basing its implementation and
API's on Win32 or Delphi, then it should adhere to their document
14 matches
Mail list logo
