Timer event and spinning mouse cursor

[AlastairP]

I have a timer event.
The timer checks records.

If the mouse is stationary when the timer is running the checks, the mouse pointer changes to a spinning wheel (Windows 10) and does not restore to normal until the mouse is moved.
If the check is negative, no update of the ui occurs. The check is very quick, 2-300 ms.
If you are moving the mouse when the check occurs, you don't see the spinning wheel at all. (Because it is quick).

How can I avoid the spinning wheel or at least reset it after the event runs. (Without moving the mouse).
I wanted to avoid users thinking the application is busy when it is not.


With thanks
Alastair

 

[Mike Lewis]

I don't think I've ever seen exactly this behaviour (and it's difficult to reproduce it). But the first thing to try is to set the MousePointer property to 0 when the process has finished.

I'm not sure whether you need to set the form's MousePointer, or that of each of the individual controls on the form. Try it both ways. If you need to do it for the individual controls, you can do that with [tt]THISFORM.SetAll("MousePointer", 0)[/tt].

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

One tip about timer events is to start with This.Enabled = .F., then do processing and finally go back to This.Enabled = .T.

It does not seem to be necessary as you tell your code is fast, but what is the interval set to?

The spinning wheel indicates heavy CPU usage, if you don't set the mousepointer property by code, the OS decides that and the only indirect influence VFP then has, if the interval is set very low, lower than the average time needed for the timer code.

As Mike also said it's hardly reproducable without knowing more, we neither know your interval number of miliseconds nor the code you do. If I imagine the record check to be a LOCATE or a SEEK or whatever looks for a record or just checking the current record for some condition, none of that would in itself turn the mouse to the spinning wheel.

So what is your interval and what is the timer event code?

Chriss

 

[AlastairP]

Good morning,
I seem to have some success so far with changing the mouse pointer. I will monitor and see if this is satisfactory.


Timer code:

this.Enabled = .f.
this.Parent.periodic_refresh()
this.Enabled = .t.

periodic_refresh:

IF this.control_in_use = .f.
	thisform.MousePointer= 13
	this.refresh_sitelist()
	thisform.MousePointer=0
ENDIF

refresh_sitelist runs a couple of checked to see if there are any changes between the temporary cursor and the base table

SELECT sites.siteid, sites.rowversion FROM sites INNER JOIN cTempSites ;
ON sites.siteid = cTempSites.siteid ;
WHERE sites.recdeleted = 0 ;
AND sites.rowversion <> cTempSites.rowversion ; 
INTO CURSOR xxCheckSiteRowVersion


SELECT xxCheckSiteRowVersion
COUNT FOR !DELETED() TO lnCount 



IF lnCount > 0

[indent]etc ...[/indent]

 

[Chris Miller]

I understand why you don't post all code, as it's not contributing to make it reproducible without also having data. It looks good to me, as long as you don't set the interval very low.

Chriss

 

[mjcmkrsr]

Hi,

Why do you set in the TIMER event

this.Enabled = .f.

It then probably doesn't do anything.

I suggest to simply put the code in the TIMER event and set the timer INTERVAL high enough (e.g. 1800000 to check every 30 minutes)

SELECT sites.siteid, sites.rowversion FROM sites INNER JOIN cTempSites ;
ON sites.siteid = cTempSites.siteid ;
WHERE sites.recdeleted = 0 ;
AND sites.rowversion <> cTempSites.rowversion ; 
INTO CURSOR xxCheckSiteRowVersion


SELECT xxCheckSiteRowVersion
COUNT FOR !DELETED() TO lnCount 



IF lnCount > 0

etc ...

hth

MarK

 

[Chris Miller]

MarK,

that's what Tamar Granor also regularly recommends doing, because the next Timer event could start while the current one is not done. For example se her paper

http://www.tomorrowssolutionsllc.com/Articles/Taking Advantage of Idle Cycles.PDF

It also is something that helps with debugging timer code. While there also is a debugger setting to not show Timer events in the trace window, if you want to debug a timer event, then surely only while the timer is disabled. And if you make that the first step of your timer event code, you are always ready for debugging.

If you don't get back to the end of the timer event setting enabled back to .T., then something is going very wrong, too, and you'd detect that.


Chriss

 

[mjcmkrsr]

Hi Chriss,

Thanks for the hint and the link - very interesting paper by T. Granor

MarK

 

[Chris Miller]

very interesting paper by T. Granor

Indeed. I actually wanted to find a paper/article/book page in which Tamar explains why she sets Enabled=.f. in timer events, but she does. Not my invention. And that article could also be applied here.

I tried to create such a case - a timer event happens while the timer event already runs and isn't finished. I couldn't enforce it, so maybe it's not necessary anymore. Can't hurt, though, if just for the enhanced debugging experience.


Chriss

 

[Mike Lewis]

I'm slightly surprised by this discussion. I've always taken it for granted that you should disable a timer at the start of the Timner event and re-enable it at the end. I can't see any reason not to do that.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[TamarGranor]

FWIW, after I wrote that article, I worked on a timer-intensive project and turning timers off (either via Enabled = .f. or setting the Interval to 0) before processing was the difference between it working and not.

Tamar