Program hangs with Doevents

The problem I've noticed is if a sub with DoEvents is running and you click and hold on the top of the application window like you would if you want to move the form to the other side of the screen, the application stops and hangs until you release it. It does the same thing if you click and hold on the forms min/max buttons. I assume that this is because the event triggered hasn't completed yet so I haven't returned back from DoEvents.

So in my example below, if you run this and click and hold the form and drag it around the screen, you will notice that the "counter" stops until you release the form. Any ideas how to get around this to keep my program from hanging?


Code:
Dim stoprequest As Boolean


Private Sub Command1_Click()
Dim counter As Long

stoprequest = False
While stoprequest = False
DoEvents
counter = counter + 1
Label1.Caption = counter
Wend

End Sub

Private Sub Command2_Click()
stoprequest = True
End Sub

Private Sub Form_Load()
stoprequest = True
End Sub

Private Sub Form_Unload(Cancel As Integer)
End
End Sub

As a wise man once said "Why would you want to do this ?"

It appears the VB6 Runtime stops when you move a screen

I guess the problem is there are litterally thousands of events which the run time checks for (on each and every control on the screen)

eg, Mouse move, mouse down, mouse over, clicks, double clicks, drag etc etc

So I guess it just says "I give up" until you put the screen down again

See the screen as a bucket

Now who in their right mind would want to be filling the bucket with more water while you are moving it across the room ??

I rest my case !!! :p

I am sure that will leave you :confused:

Move up to .NET and use Threading

Silverlight!

We put a MOVE UP and MOVE RIGHT command into the CLICK_EVENT of a control that just looped around a circle.

As soon as you tried to click it, it moved away as soon as you tried to click it

you can also try to put sleep command within the loop to ease the CPU load

Thanks everyone for the suggestions. Let me give you a little more background:

I'm working on a small application that needs to have accurate timing resolution (+/-5mSec). I am using timeGetTime from the windows multi media dll library. Once the user starts the program, I sit in a sub comparing current time versus elapsed time. Once I reach my desired timeout, I execute a call to another sub, perform some tasks, refresh a listbox and return back to wait for another timeout. While waiting for the timeout (10-20mSec) I run DoEvents. I stay in the sub waiting for the timeout until the user hits the stop button. Basically my program is sending timed messages on an external data bus, the message have to go at regular intervals. Everything works fine until the user moves the form window or they use one of my pull down menus. Once they do that, the messages until they release.

I started looking at .Net, at least with this I can take advantage of background threads.

I actually made a solution with threading in VB6, but they are known to crash. Worked great in debug mode though. lol

Tried API's:
CreateThread
SHCreateThread

In other words... VB.Net might be closer to the answer you need.

Of course, less than 15ms is probably going to be a problem, unless you use an external clock and trigger

Quote:

---

Originally Posted by clay1

...I'm working on a small application that needs to have accurate timing resolution (+/-5mSec). I am using timeGetTime from the windows multi media dll library. Once the user starts the program, I sit in a sub comparing current time versus elapsed time. Once I reach my desired timeout, I execute a call to another sub, perform some tasks, refresh a listbox and return back to wait for another timeout. While waiting for the timeout (10-20mSec)

---

I wonder about this small timeout because human reaction normally is longer then 100 ms so nobody can hit a key exactly in one of this timeout periods. While this may not matter as the keystroke or mouse move event simple appears in another one of this periods, you may have troubles with the timer itself. Most timers are not such precise as you want. The other thing is that as long as you have one thread all messages are going to a message queue which then will proceed one after the other. Result: You cannot solve your probem as long as you only have one thread running, because anything the user does also is going into this queue of things to be proceeded and this will delay or stop your timer, because your program will come back to your time-comparing-routine- much to late.
So the only solution is - dont use VB6 for this. Use any .net language, where you can do multithreading. As you said yourself

Quote:

---

at .Net, at least with this I can take advantage of background threads.

---

For the most part the timer I'm using has enough resolution. As long as the program keeps responding everythings OK. I did notice this morning that in my example, if you change the forms Movable property to False, the program(timer) doesn't stop. However, if you right click on the title bar to get the move/close popup, the timer stops. I know it's not really the time that stops, for whatever reason, there is an event that doesn't return back from Doevents until the popup closes.

This is really the point of my example program. To show that there are some event/s that don't return back from Doevents until the user finishes. What I need is a DoSomeEvents function that would only do events I specify. All I'm trying to do is keep the timer running no matter what the user does. This is really more of an annoyance that anything else.

One more thing I can say, a callback timer works just fine no timer/program hangs. Assuming the resolution is acceptable, I'm going to try a callback timer that has a faster timeout, inside this I'll check timeGetTime for my accurate 10milli second timeout.

If you use VB.Net, you can create different THREADS that allow background processing as well

Quote:

---

Originally Posted by clay1

... All I'm trying to do is keep the timer running no matter what the user does. This is really more of an annoyance that anything else.....

---

Thats exactly what cannot be done. No one can promise that. You simple need to understand some simple words like singlethreaded and Do-Events and you will understand that this allows to complete the next event in the queue of events. If the next event needs longer then your 15 ms then you cannot get back to the originals early enough. You even dont know how many of callback events in between have accumulated on the queue so they, maybe after a 'long' lasting DoEvents action, will be done one after the other. Its like a car jam on the highway. Even when the cars 1000 m behind the jam are coming one after the other each one 50 m distance from the next, they come out of the jam one after the other 3m Distance each.
So your callbacks will come to the queue every 15 msec, but are they processed in the same way ? YOU CANNOT GRANT THIS. NEVER.
If you get in one delay, all others will have to wait and then they process in the same speed as they are in the queue. One after the other no timelag in between them. Its up to the receiver program to be able to receive packeges independent if they have different timelags. The timeout for such an action is normally in the range of seconds not 5 msec.
And you even cannot grant this when a user opens a modal Dialog and doesn't close it 3 minutes and this event waits for finishing and doesn't come back before. There is no secure way then multithreading with at least one separate thread.

I was playing around with the idea a little more, and remembered that you can make another application(a thread) that does just the counting.
I used the DrawText API, as a label for updating on the first application.
All that's left, is to hook up the buttons, so that they communicate with the second application, to start/stop the counter.
You'd also want to hide the second app.
The first app is free to update it's label(Drawn by app2) no matter what the user is doing to the first app.

API's
GetDC
DrawText
FindWindowEx
PostMessage or SendMessage

Much easier to just use .NET.
If that's not an option, then give it a try.