On Thursday 03 of November 2011 21:30:19 Sven Barth wrote:
> Am 02.11.2011 19:25, schrieb Ludo Brands:
> > Apparently not everything is that transparent under windows:
> > http://msdn.microsoft.com/en-us/library/windows/desktop/ms724944%28v=vs.8
> > 5%2 9.aspx
> >
> > "To inform Explorer that the
On Thursday, November 03, 2011 03:11:37 pm Hans-Peter Diettrich wrote:
> Pete Cervasio schrieb:
> > > Splitting the TDateTime into year, month etc. is done by a
> > > DecodeDate...
> > >
> > > function, that *assumes* that TDateTime contains a local time. When
> > > you
> > >
> > > feed it
Am 03.11.2011 18:15, schrieb Hans-Peter Diettrich:
zeljko schrieb:
This is what MSDN says about GetTickCount:
Retrieves the number of milliseconds that have elapsed since the
system was started, up to 49.7 days (what they do after 49.7 days ? ).
When the DWORD overflows, Win9x stops to work
Am 03.11.2011 17:38, schrieb Hans-Peter Diettrich:
Sven Barth schrieb:
FPC's Now on Windows uses GetLocalTime as well. For its implementation
please take a look here:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/time.c?revision=52912&view=markup
(line 277ff)
That
Am 02.11.2011 19:25, schrieb Ludo Brands:
Apparently not everything is that transparent under windows:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724944%28v=vs.85%2
9.aspx
"To inform Explorer that the time zone has changed, send the
WM_SETTINGCHANGE message."
WM_SETTINGCHANGE s
Am 03.11.2011 21:11, schrieb Hans-Peter Diettrich:
Pete Cervasio schrieb:
> Splitting the TDateTime into year, month etc. is done by a
DecodeDate...
> function, that *assumes* that TDateTime contains a local time. When you
> feed it an UTC time, the result is unusable.
What? How does it assu
Pete Cervasio schrieb:
> Splitting the TDateTime into year, month etc. is done by a DecodeDate...
> function, that *assumes* that TDateTime contains a local time. When you
> feed it an UTC time, the result is unusable.
What? How does it assume it's in local time? It assumes it has received
On Thursday, November 03, 2011 11:03:36 am Hans-Peter Diettrich wrote:
> Sven Barth schrieb:
> > And functions like DateTimeToStr don't care whether a time value is
> > local or UTC and in my opinion they even MUST NOT.
>
> Splitting the TDateTime into year, month etc. is done by a DecodeDate...
>
On Thu, 03 Nov 2011 17:38:01 +0100, Hans-Peter Diettrich
wrote:
FPC's Now on Windows uses GetLocalTime as well. For its implementation
please take a look here:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/time.c?revision=52912&view=markup
(line 277ff)
That
zeljko schrieb:
This is what MSDN says about GetTickCount:
Retrieves the number of milliseconds that have elapsed since the system
was started, up to 49.7 days (what they do after 49.7 days ? ).
When the DWORD overflows, Win9x stops to work properly. NT uses an
bigger data type, at least int
Sven Barth schrieb:
FPC's Now on Windows uses GetLocalTime as well. For its implementation
please take a look here:
http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/time.c?revision=52912&view=markup
(line 277ff)
That code doesn't make sense, without additional infor
Sven Barth schrieb:
Am 03.11.2011 02:39, schrieb Hans-Peter Diettrich:
IMO we have to face a problem very similar to Ansi/UTF-8/16: A TDateTime
variable can contain local time in a number of timezones (Ansi), or UTC
values (UTF), which must be interpreted accordingly, e.g. in
DateTimeToStr().
W
Hi,
I can pass an array of TVarRec to a procedure that expects an array of
const like below:
procedure Test(Args: array of const);
begin
//do something with args
end;
var
a: array of TVarRec;
s: String;
begin
SetLength(a, 2);
a[0].VType := vtInteger;
a[0].VInteger := 3;
a[1].VT
On Thu, 3 Nov 2011, Graeme Geldenhuys wrote:
If you want to do timing, you can also take a look at EpikTimer. I
believe it doesn't work on all platforms that FPC supports, but it
works on the big three (Windows, Linux, Mac).
PLEASE NEVER MENTION EPIKTIMER AGAIN.
it returns Now() on all plat
Am 03.11.2011 03:12, schrieb Hans-Peter Diettrich:
Also note that on platforms like Windows this would be a unnecessary
call as there the current(!) timezone bias is located in a shared
memory area which is mapped into each process by the kernel.
I don't think that this really is how Windows wo
Am 03.11.2011 02:39, schrieb Hans-Peter Diettrich:
IMO we have to face a problem very similar to Ansi/UTF-8/16: A TDateTime
variable can contain local time in a number of timezones (Ansi), or UTC
values (UTF), which must be interpreted accordingly, e.g. in
DateTimeToStr().
When Delphi compatible
On Thu, Nov 3, 2011 at 9:41 AM, zeljko wrote:
> I guess that there's no GetTickCount in RTL.
> Is it possible to add it there ?
If we are going to add this I would prefer to get the result in
microseconds. If the platform doesnt support, then just multiply the
result, but still allow the possibil
If you want to do timing, you can also take a look at EpikTimer. I
believe it doesn't work on all platforms that FPC supports, but it
works on the big three (Windows, Linux, Mac).
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI
On Thu, November 3, 2011 09:41, zeljko wrote:
> I guess that there's no GetTickCount in RTL.
> Is it possible to add it there ?
> Why ?
> Because current GetTickCount in lazarus uses Now() which is movable
> backward/forward by ntpd under unixes, and that could be a huge problem.
>
> This is what M
Al 03/11/2011 9:41, En/na zeljko ha escrit:
Retrieves the number of milliseconds that have elapsed since the system
was started, up to 49.7 days (what they do after 49.7 days ? ).
It starts again from 0.
If you're using it to time events (i.e.
ElapsedTime:=GetTickCount-StartTime), it's not a
Withdrawn.
It is only partially true.
Still it can not be expanded and can overflow easily.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Did anybody mention gettickcount is documented as microtiming?
And should not be expanded?
On 3-11-2011 9:57, Marco van de Voort wrote:
In our previous episode, zeljko said:
So, according to POSIX clock_gettime(CLOCK_MONOTONIC) is supported on
linux, bsd and others, and in that case we can have
On Thursday 03 November 2011 09.08:35 zeljko wrote:
>
> That's pretty big difference. Can you compare NowReal() from attached
> program with your functions ?
>
Linux
FPC Now() MSEgui nowutc() MSEgui nowlocal() NowReal()
10.28s 3.45s 3.55s 9.86s
Martin
___
In our previous episode, zeljko said:
> > So, according to POSIX clock_gettime(CLOCK_MONOTONIC) is supported on
> > linux, bsd and others, and in that case we can have exact GetTickCount.
> > If there's no support for monotonic clock on some platform , now() can be
> > returned anytime.
> Forget
On Thursday 03 of November 2011 09:41:05 zeljko wrote:
> I guess that there's no GetTickCount in RTL.
> Is it possible to add it there ?
> Why ?
> Because current GetTickCount in lazarus uses Now() which is movable
> backward/forward by ntpd under unixes, and that could be a huge problem.
>
> This
I guess that there's no GetTickCount in RTL.
Is it possible to add it there ?
Why ?
Because current GetTickCount in lazarus uses Now() which is movable
backward/forward by ntpd under unixes, and that could be a huge problem.
This is what MSDN says about GetTickCount:
Retrieves the number of milli
On Thursday 03 of November 2011 08:43:55 Martin Schreiber wrote:
> On Thursday 03 November 2011 08.04:17 Martin Schreiber wrote:
> > On Thursday 03 November 2011 07.44:47 zeljko wrote:
> > > > The results with 10'000'000 calls:
> > > >
> > > > FPC Now() MSEgui nowutc() MSEgui nowlocal()
> > > >
>
03.11.2011 15:29, zeljko wrote:
Maybe it's not problem *now*, but looking into mailing list ppl have a
lot of problems, so I think that fear is only problem (at least for me).
People mostly expressed their FUD although there were few problems and
there are some.
But why do you think they sh
On Thursday 03 November 2011 08.04:17 Martin Schreiber wrote:
> On Thursday 03 November 2011 07.44:47 zeljko wrote:
> > > The results with 10'000'000 calls:
> > >
> > > FPC Now() MSEgui nowutc() MSEgui nowlocal()
> > >
> > > Linux
> > >
> > > 15.29s 3.39s 3.57s
> > >
> >
On Thursday 03 of November 2011 08:11:16 Paul Ishenin wrote:
> 03.11.2011 15:04, Martin Schreiber wrote:
> > No, I can not use trunk because of cpstrnew. I'll try the file Michael
> > sent.
>
> If it is not difficult please explain exact problems with cpstrnew you
> have in a separate thread. It i
On Thursday 03 November 2011 08.11:16 Paul Ishenin wrote:
> 03.11.2011 15:04, Martin Schreiber wrote:
> > No, I can not use trunk because of cpstrnew. I'll try the file Michael
> > sent.
>
> If it is not difficult please explain exact problems with cpstrnew you
> have in a separate thread. It is i
03.11.2011 15:04, Martin Schreiber wrote:
No, I can not use trunk because of cpstrnew. I'll try the file Michael sent.
If it is not difficult please explain exact problems with cpstrnew you
have in a separate thread. It is important to know for me what problems
do you have with the new ansis
32 matches
Mail list logo
