Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

"Not Responding" in title bar of form

"Not Responding" in title bar of form

"Not Responding" in title bar of form

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?

RE: "Not Responding" in title bar of form


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 Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: "Not Responding" in title bar of form

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 Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: "Not Responding" in title bar of form

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


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

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

RE: "Not Responding" in title bar of form

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:

CODE -->


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


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.

RE: "Not Responding" in title bar of form

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


Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close