FPD2.6 & System time/date under hibernation

[cricket]

When FPD2.6 runs on a computer which goes into hibernation in Win XP (e.g. on a laptop when lid is closed) Foxpro's clock stands still (i.e. the resume time is the same as the close down time).

This is very error prone when time and date critical data is being entered, where Foxpro time is deemed to be the transaction time.

I get over the problem in our Netware 4.2 environment, by running the SYSTIME command which synchronises Foxpro time with the server. Note: Foxpro only - not the Win XP system time. Other networking systems have similar facilities for time sysnchronisation.

This does not cause a problem on VFP8, which appears to refresh it's clock.

Is there a way to have FPD2.6's time updated from system time other than QUITting?

 

[ezopaci]

What about system command DATE ? Which date does it print ?
If system (dos) date is updated correctly, there is some technique to get system date even from dos foxpro.

Tomas

 

[DSummZZZ]

Is there a way to have FPD2.6's time updated from system time other than QUITting?

I don't believe there is a way.
Foxpro's clock is initialised at Foxpro startup. So if the entire app 'sleeps', the clock won't keep running.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[rgbean]

I agree with Dave, because it's a DOS application, it expects that it's the only thing running. If the Windows environment switches it out it'll loose that time. In fact it's one of the reasons that under NT/2000/XP/2003 a DOS app shows it's using all the processor time.

Rick

 

[ezopaci]

To DSummZZZ:
Yes, I know, but If dos will update date correctly, you can read DOS date from foxpro without call foxpros DATE() function. In your program simply change calling DATE() by myDate().

To rgbean:
If you switch active window from dos application (in NT,...) dos application gets lower, but still, time slices of cpu time. Reason why dos applic. consumes 100% cpu is because dos program does not "sleep". Dos prgram every time something do, even only test keyboard.
Did you try my FOXFREE.COM ? You can search it by google.
(keyword FOXPRO and FOXFREE).


Tomas

 

[TheRambler]

FOXFREE can be found here.

 

[cricket]

I have persisted with finding a solution, and the following seems to work:

Issue the command (or build it into the program)

RUN cmd.exe /C time /t

This appears to reset FPD's internal system clock to WinXp time.

I have only briefly tested it. DATE() appears to be extracted directly from the WinXp clock - i.e. if you issue the DATE() command in FPD, and then change XP's date, you will get the correct date when you issue DATE() immediately after the change.

I will need to check behaviour, when time is changed from before midnight to after midnight

 

[cricket]

I tested laptop hibernation through midnight.

I shut down at 9pm.
On restart at 8am I issued
? date() which gave the correct new date without any intervention
? time() which gave 21:10

When I ran RUN cmd.exe /C time /t , FPD time was the same as WinXP (or computer motherboard) time.

Programmers should protect against this time issue in FPD.