Timed Refresh 2

[isaiah25]

Working with VFP 8, I have created an app that monitors a number of things within my work realm. I have a particular screen which summarizes a number of events and activities on a real-time basis with a timer set at 60 seconds driving the refresh. It's all good... and fully automated... except that I have a lot going on behind the scenes and the mouse can only access the screen controls (as a non-hourglass icon) for the last 6 or 7 seconds. Obviously this is not long enough even to click on an on-screen icon to trigger a hard-copy report.

Is there another way to handle this so that all the background grunt work happens "somewhere else" and then just a second or so is spent in refreshing and repainting the screen with updated data, leaving the mouse a 59 second useful life between refreshes?

 

[JRB-Bldr]

"an app that monitors a number of things within my work realm"

Like when its time to take a break and/or go home for the day based on amount of work load! Probably not. Oh well.

Regardless, the way that I would approach resolving what you describe would be to have things occur in 2 totally separate applications (one for the GUI and one for the 'realtime' event monitoring) which could run concurrently and 'talk' to each other via data flags, etc. which were written to and read from one or more control tables.

Good Luck,
JRB-Bldr

 

[Mike Lewis]

I completely agree with JRB-Bldr. In fact, I have a very similar situation in my current project.

Have the foreground app launch a separate executable to handle the background tasks. Launch if via RUN or ShellExecute() - not via a DO command. That way, the apps will run independently of each other.

In the background app, do the stuff you have to do in a simple loop. But, each time round the loop, execute a Sleep() API call, with an argument of, say, 120 seconds. That way, other processes will be able to run while the background is sleeping.

The only slight problem is the communication between the UI and the background - assuming they need to communicate. If so, the only simple way to do that is by reading and writing values to and from a common table. It will slow things down very slightly, but off-hand I can't think of a better way.

Hope this helps.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[isaiah25]

Excellent idea guys - both of you. Honestly, that NEVER would have occurred to me. I'll put on a fresh pot of coffee and get right into it!

Thank you!

 

[Mike Lewis]

Let us now how you get on.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business