Timer controlled clock not updating during processing 2

[monkey666]

I display the current time in a custom status bar using a timer with "this.parent.statusbar.value=ttoc(datetime(),2)" in the timer's timer event.

This works fine until other processes occur called from the same form (appending records etc) during which the clock does not update. As soon as the processing has finished the clock continues to update as normal. Is this a case of low system resources?

monkey

 

[DSummZZZ]

It's more of a case of VFP taking over the record update and not bothering to refresh the screen. Normally, this is a good thing.
If it's imperative you have the clock running though, you may want to try using the VFP clock; SET CLOCK ON / TO.
I believe it will keep updating. It will slow down the performance of your file updates though.
Dave S.

 

[monkey666]

Thanks for the reply but i should have mentioned that this is occuring in a a foxpro created EXE, and without the main foxpro screen so SET CLOCK isn't really an issue.

I guess Foxpro is busy doing all the (intensive) file stuff and isn't refreshing the form properly.

Thanks

monkey

 

[darrellblackhawk]

Monkey:

You can issue DOEVENTS periodically in the processing loop to allow the timer to fire. The problem with this, as DSum's post mentions, is that it will slow down the processing loop.

If you truly need the custom clock, you could create another instance of VFP in the background and have it handle the clock display, although you'll need to place the clock on it's own form - say 24 to 30 pixels high, the width of your main form, and abutting the bottom.

This method of course will increase memory usage, so you'll have to be carefull on machines running below XP or 2000.

The main benefit of using a separate instance is that it won't be limited by the processing loop's CPU usage. Thus, the clock will update properly and on time.

I'd encapsulate the second instance/clock in a class so it's reusable across applications.


Here's a base to start with:

_vfp.visible = .f.

o = createobject("oForm&quot

o.show

read events

_vfp.visible = .t.

define class oForm as form

docreate = .t.
width = 800
height = 24
top = 100
desktop = .t.
showwindow = 2
titlebar = 0

add object cmdOne as commandbutton with;
visible = .t.,;
height = 24

procedure destroy
clear events
endproc

procedure cmdOne.click
thisform.release
endproc
enddefine

You can add your custom clock/timer to the form and voila! A custom status bar not affected by the main program. Of course you'll have to position it properly and drop the status bar from your main form.

There is a major problem with this method! You'll have to create some type of methodology to allow form resizing, and since you'd be dealing with two instances of VFP, they'd need to talk to each other. And that's the big rub... The processing loop gets in the way again. I think after all this, I'll try to implement this for the fun of it.

Hope this helps,

Darrell 'We all must do the hard bits so when we get bit we know where to bite'

 

[darrellblackhawk]

Of course you could just maintain a variable in the processing loop to determine when to issue the DOEVENTS.

e.g.

* Start processing loop

local nWhenToFire

nWhenToFire = seconds()

scan while

... do a bunch of stuff

if Seconds() - nWhenToFire >= 1

* Timer/clock object will fire along with
* any other pending events

DOEVENTS

nWhenToFire = seconds()

endif

endscan && End processing loop

Of course the above won't compensate for crossing midnight, but this shouldn't affect your custom clock function, as it should be designed to get the current time anyway.


Darrell
'We all must do the hard bits so when we get bit we know where to bite'

 

[Boudewyn]

on the UT is a timer library (timers.fll) with a timer that will fire always! look for cpptimer written by bela bodecz. Easy to use, simple to configure!

Boudewijn