Hello,

I want to start a timer and loop until the timer expires. It appears that if I use the following code the Timer1_Tick event never occurs.

Code:

    ' Start timer
        Timer1.Enabled = True

        While Timer1.Enabled <> False
                  'loop until 10 millisecond timer expires
        End While

Is there another way to do this?

Thank you,

You are using the Timer wrong. This is the correct way to start a timer:-

Code:

    Timer1.Interval = 100
            Timer1.Enabled = True

BTW you're signiture and avatar are really funnie haha.

I actually think that looping that would not be the best way to acomplish what you're trying to do. There is a way to make a thread sleep for a certain ammount of miliseconds. Try this:

Code:

Threading.Thread.Sleep(miliseconds)

Threading.Sleep is rarely the right answer. If it is on the UI thread, the interface will appear to freeze. From reading this forum, I would have to say that most of the times that people reach for .Sleep, it is a sign that they are misunderstanding something. Of course, it would be a bit novel if sleep caused a lack of comprehension, and a lack of sleep has rarely been correlated to better comprehension, but that's just a necessary play on words.

The timer doesn't set itself to False, it just raises a Tick event every time the interval elapses. Therefore, you set the timer interval, start the timer, then do nothing more in that method. You would also need to have a method that handled the timer_tick event, and that is where you would put the code that you wanted to do when the timer expired. The timer will keep on running, though, raising an event every time the interval elapses, so you need to stop the timer in the tick event handler if you don't want ticks to be raised every x time.

Also, a timer has a minimum resolution that is around 50ms, so a 10ms timer won't really time 10 ms. If you really need timing that fast, perhaps you could tell us why and we could suggest some alternative.

are you timer1.enabling in the timer_tick? because that would be why it never begins...

That's not actually why the event never appears to be raised. What is happening is that right after the timer is started, the code goes into this busy loop:

While Timer1.Enabled <> False

Since Timer1.Enabled is NEVER false, this condition evaluates to True, and the process continues to spin on that loop for the rest of time. The events raised by the timer queue up, but they won't interupt that loop, and since the loop will never stop, the events just sit on the message queue without ever being processed.

Common wrote:

That's not actually why the event never appears to be raised. What is happening is that right after the timer is started, the code goes into this busy loop:

While Timer1.Enabled <> False

Since Timer1.Enabled is NEVER false, this condition evaluates to True, and the process continues to spin on that loop for the rest of time. The events raised by the timer queue up, but they won't interupt that loop, and since the loop will never stop, the events just sit on the message queue without ever being processed.

My Timer1_Tick event handler is as follows:

Code:

 Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer1.Tick

        Timer1.Enabled = False

    End Sub

Right, but that line will only occur if the timer tick event gets handled. When the timer ticks, it raises the event, but execution is stuck on your perpetual loop, so that event just sits on the message queue. Messages are taken from the queue when the process gets a chance, but it will never get a chance because it is perpetually spinning in that loop. The event isn't going to interrupt the loop, it just puts a message on the queue, and the queue only gets pumped when your loop ends....which means NEVER.

Common wrote:

Right, but that line will only occur if the timer tick event gets handled. When the timer ticks, it raises the event, but execution is stuck on your perpetual loop, so that event just sits on the message queue. Messages are taken from the queue when the process gets a chance, but it will never get a chance because it is perpetually spinning in that loop. The event isn't going to interrupt the loop, it just puts a message on the queue, and the queue only gets pumped when your loop ends....which means NEVER.

OK. I'm new to VB and thought that events were like interrupts. Can you suggest a better way of doing nothing for 10 microseconds while I'm waiting for an external device to finish processing serial data my VB application has sent it?

Thank you,
steve@macinstruments is offline Reply With Quote

I'm not sure about the "10 microseconds," but I would suggest that you increment a variable inside the timer's tick event and wait until it reaches a certain number (ie. fire the tick event every "microsecond" and when the counter variable hits 10, take some kind of action.

Fremo wrote:

I'm not sure about the "10 microseconds," but I would suggest that you increment a variable inside the timer's tick event and wait until it reaches a certain number (ie. fire the tick event every "microsecond" and when the counter variable hits 10, take some kind of action.

Thank you very much.

If this is serial port related you don't need a timer, except maybe to check that you did NOT receive data. The serial port fires an event when it has received some data.

One issue I mentioned before is this: 10ms is too fast for the timers. They won't be that responsive. A Threading.Timer has a finer resolution, but I'm not sure that even that is as fine as what you are talking about. Of course, if you are really talking about microseconds rather than milliseconds, then none of the timers has a chance of being sufficient.

As a general rule, you HAVE an interrupt, it just doesn't really interrupt anything. It sounds like you are thinking about the program in a linnear fashion rather than an event driven fashion. You were starting a timer, then expecting it to interupt the code a few lines after it was started, which would be a linnear approach. In an event driven world, when you start the timer, that's pretty much the end of that method. When the event is raised, that's where execution resumes, so your Tick event handler doesn't just disable the timer, it also runs all the code that you would have run after that loop had ended.

In a linnear world, you are thinking: Do this, then do this, then do this, etc. In an event driven world, you would be thinking: When this event occurs, I want to take this action.

Starting the timer with an interval of 100 only means that you will get an event in about 100ms. What you do when that event occurs is what you put in the event handler. You don't use the event handler to signal back to some 'main code', which would be a linnear model.

Still, that timer is too fast. What are you trying to do with it? I don't know where DB got the serial port stuff, but if it is anything like that, there is a different way to go about it.

In the post, toothfairy said "...a better way of doing nothing for 10 microseconds while I'm waiting for an external device to finish processing serial data my VB application has sent it?"

BTW - 10 microsecond delays are not possible, and 10 milliseconds is not likely.

Ah, I missed that.