> CF supports it - most CE devices don't. Theres a good reason for it that I
> won't go into, but the workaround is to use Environment.TickCount property.
[quoted text clipped - 17 lines]
> >
> > Andreas
The tickcount is not really appropriate for counting milliseconds on a scale
over minutes like that with any accuracy. It's actually returning the
number of system ticks since boot. While that in theory is the number of
milliseconds, some drift can be expected, and how the implementation of the
OAL is handled can have a big impact on this - adding a sleep/wake cycle in
the middle of it could also add complication. Do you really need millisecod
resolution over such long periods of time, and even through a sleep/wake?
-Chris
>I made a working stopwatch using the Environment.TickCount property and
> discovered that when my device is automatically turned off avter 3
[quoted text clipped - 32 lines]
>> >
>> > Andreas
Andreas Ringdal - 21 Jan 2006 17:00 GMT
No, most of the time I wont need milliseconds, but I'm working on
several smaller projects in order to get to know the compact frameworks
limitations and possibilities. Want to make an all purpose stopwatch
while I'm at it.
The main reason for writing the stopwatch application is to log my wifes
labour contractions and as a techhead I really can't do that using an
ordinary watch and writing down the time for each contraction.
Hope the application gets ready in time :)
<ctacke/> skrev:
> The tickcount is not really appropriate for counting milliseconds on a scale
> over minutes like that with any accuracy. It's actually returning the
[quoted text clipped - 38 lines]
>>>> but
>>>> on my device (qtek 9100 / HTC Wizard), WM5. Milliseconds is always 0.