www.virtualacorn.co.uk/forum

I'm running into some peculiar issues trying to get a scheduled task to drive NetSurf.
What is supposed to happen is Alarm runs a program that runs NetSurf if its not already running, sends it a wimp message to go to the ADSL router URL, waits for the page to be rendered, saves the page as a text file, closes the NetSurf window, parses the file, calculates some statistics and saves them in a CSV file. This all works perfectly most of the time and if VRPC is full screen and I'm working with it the whole sequence works a treat.
However, when VRPC is unattended for a while, the sequence works right up until the point that it should save the page to a text file, and there it sits motionless until I come along. As soon as I move the mouse it bursts into life and saves the file and continues normally. The data in tha file shows that the page was rendered at the correct time, and the real time clock reading was taken at the correct time, but the file was saved perhaps an hour or two later (when it burst into life).
I have tried various alternative wimp polling strategies and have found unless I actually put up a message dialogue window, and periodically reopen it while waiting for the web page to render, the polling of all the open NetSurf windows for one of the correct name fails to see the window. I've overcome this for the case where I'm working on the computer, but when its unattended the process sometimes works immediately and other times VRPC seems to go to sleep even though my application is actively checking for the presence of the appropriately named NetSurf window.
Can anyone offer an explanation (and better still a solution)?
Mike

That's a really weird one. My first thought (and I could be wrong) is that the power management is being too agresive on your machine and when it's unattended it all goes into sleep mode (I wonder if this is related to the clock problem on another thread?).
So try disabling the Power Managament - firstly in VRPC and then in Windows to see if this helps track the problem down.

OK, this is my fault! I instrumented the code and realised the execution context is subtly different between running the job manually and running it as a scheduled task. This meant that the timed waits returned without waiting and things got horribly confused. This might actually affect a few other things that I've had problems with recently but it took a while to track this one because its one of those problems where when you examine it everything works perfectly and when you leave it to run automatically it fails.
This doesn't have any connection with the clock problem in another thread.