"Not Responding" in title bar of form

[AlastairP]

I have had a look through a few forum posts and it seems "DOEVENTS" may be the way to help with this.
I have a process that takes about 30-40 seconds to run, and during this process there is some waiting for responses from external servers.
There is also some Scan/endscan components.
Sometimes I get "Not Responding" in the title bar, which goes away when the process is completed.

I see in the help file that DOEVENTS "Executes all pending Windows events."
Is there anything I need to be concerned about or should I be liberal in placing DOEVENTS in my loops/scans?

Also should the placement of the command be at the end of the code in the loop? Where else can I place this command in code sequences?

I have had issues in the past with labels etc not visually changing during a loop, for instance progress bars or other visual progress indicators . . . will DOEVENTS help with this also?

 

[Mike Lewis]

Alastair,

I don't know if this helps answer your question, but I have always placed DOEVENTS in a loop where there is a potential for execution to be interrupted. One example of that would be if the user can press ESC or click a Cancel button in order to cancel the process. The point is that the keypress or click wouldn't otherwise fire an event until the processing loop has finished; the DOEVENTS allows the event to fire, giving your program a chance to respond.

As for the number of times you execute DOEVENTS within a given loop, the more you do that, the more responsive your program will appear to be, but the slower the overall performance. It's a simple trade-off. The only way you'll know where to draw the line is to experiment.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Just to add to my previous post, I just noticed this in HackFox:

issuing DoEvents frequently is hazardous to your application's performance, by an order of magnitude in some cases ... even a single DoEvents is pretty time-consuming

So that would be an argument for using it sparingly.

To answer your other question, it won't make any difference where you put it within the loop: the start, middle or end.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

With a customer providing a POS application on touchscreen devices I had the bad experience a DOEVENTS can take really long times, I measured that by having coverage logging, and a single DOEVENTS took over 30 seconds!

Seems unbelievable, but the whole thing seemed to be caused ba the single simple difference a touch screen system has from a normal desktop system: No mouse and thus rarely any mousemove events.

So I can confirm this can take quite some time. It wouldn't matter if you wait for something to happen, ie. waiting for a readystate change of the internetexplorer.application or an xmlhttp request this will happen and you actually don't have anything else to do when you're waiting.

But this alone doesn't explain why a process would become unresponsive, because the slightest mouse move does wake up the process and lets it process that event, so actually you become very responsive - to events. But your iterations might slow down.

What should happen in case no event is in the event queue is you get back to code execution right away.

It#s a glitch, that likely will not affect you, though, I haven't had this in any other case than that POS system with user interface based on the touchscreen alone. They don't have keyboard or mouse, the only other input device is a barcode scanner - which acts as keyboard input. But, well, it's only used when you scan products.

Anyway: Here's a little demo of what happens without DOEVENTS:

_vfp.AutoYield = .F.
lnNow = Seconds()
Do While Seconds()<lnNow+10
EndDo

_vfp.AutoYield = .F.
lnNow = Seconds()
Do While Seconds()<lnNow+10
   Doevents Force
EndDo

Hint: Copy this inro the ccommand window, select it and right-click->execute selection. Then try to type into the command window within the next 10 seconds. In the second variant you can do that, because of the Doevnets FORCE, especially the FORCE option. Without it, VFP becomes unresponsive just like without it. What can keep VFP responsive is setting _VFP.Autoyield = .T., too you might want to have this .F. because of some OCXes being sensitive about this behaviour of the VFP runtime, though. So Autoyield likely is not the solution. Very likely it s .T. anyway, as that's its default and since you have problems, your tight code iteration prevents processing the event queue of Windows more than autoyield can come up against.

So DOEVENTS, more specifically DOEVENTS FORCE does more good than harm in situations you wait for something. And yes, it also allows the form to refresh/redraw while the method you currently run is not yet finished. It's slowing down things if used everywhere simply to enforce responsiveness of the VFP process. Most things don't take long and you don't need to slow that down by introducing DOEVENTS. But for things that you know take longer it's good to use it, especially when you're waiting anyway.

You can also base an HTTP request class on a timer that starts a request in init and waits for the response in the timer event, then you're not burdening your main process with waiting for a HTTP response.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[vernpace]

You can build an EXE COM server (using the Session class) to handle those type of processes. The other concern is that you do not want users disrupting a long running process. Believe me, they will try. You can do this:

ShowCursor(0)
BlockInput(1)

Call EXE COM server process, optionally getting return value(s)

BlockInput(0)
ShowCursor(1)

The ShowCursor API shuts the mouse cursor off (0) and on (1)
The BlockInput API blocks all mouse and keybord input (1) and turns it back on (0)

This way, you dont have to deal with DOEVENTS, DOEVENTS FORCE and the "Not Responding" title bar issue.

 

[AlastairP]

Thanks, I have some options. Will test and report back.


Alastair