Can't get focus to change from one button to another

I am working on a timing program and have a start button programmed to clear all the variables and start timing events. I have another button programed to stop the timing and show the data. The problem is that when I place the cursor on the start button and press the left mouse button it workes fine, but when I move the cursor to the stop button and press the left mouse button the start buttons 3D showes that it was pressed? Since the start button clears all of the data there is nothing to display in the text boxes. If I press the left mouse button again the stop buttons 3D shows that it was pressed. Have looked everywhere for a hint as to what to do but have found nothing yet.

That's pretty weird. Can you post the code, especially the button event handlers, or the whole program?

Does the start button press when you click on other controls too?

Yes if I hit any button the focus stays with the first button pressed until you press the button the second time. I will post the code tonight.

Here is the point in the program where I look for the button to be pushed this code works, but it won't allow the focus to change when I place the cursor on the stop button.


Select Case Index
Case CMDSTART 'If the start button was pushed System is armed for race

'iniytilize Module and get Id
Ret = DioInit("TIMINGIO", Id)
' Error process
Call DioGetErrorString(Ret, szError)
'Edit_ReturnCode.Text = "Ret = " & Ret & ":" & szError May not be needed!

'Get status of the Inputs

Do Until Finished
Ret = DioInpBit(Id, 0, Start)
Ret = DioInpBit(Id, 1, Start1)
Ret = DioInpBit(Id, 2, Start2)
Ret = DioInpBit(Id, 3, Start3)
Ret = DioInpBit(Id, 4, Start4)
Ret = DioInpBit(Id, 5, SixtyFt1)
Ret = DioInpBit(Id, 6, SixtyFt2)
Ret = DioInpBit(Id, 7, SixtyFt3)
Ret = DioInpBit(Id, 8, SixtyFt4)
Ret = DioInpBit(Id, 9, Speed1)
Ret = DioInpBit(Id, 10, Speed2)
Ret = DioInpBit(Id, 11, Speed3)
Ret = DioInpBit(Id, 12, Speed4)
Ret = DioInpBit(Id, 13, Finish1)
Ret = DioInpBit(Id, 14, Finish2)
Ret = DioInpBit(Id, 15, Finish3)
Ret = DioInpBit(Id, 16, Finish4)
Ret = DioInpBit(Id, 17, RaceDone)

Application.DoEvents()


If Start Or Started Then Started = True

Do Until Started ' I need this loop to run only until Started is set


If Start1 = 1 Or lane1red = 1 Then lane1red = 1
If Start2 = 1 Or lane2red = 1 Then lane2red = 1
If Start3 = 1 Or lane3red = 1 Then lane3red = 1
If Start4 = 1 Or lane4red = 1 Then lane4red = 1


Ret = DioOutBit(Id, 0, lane1red)
Ret = DioOutBit(Id, 4, lane2red)
Ret = DioOutBit(Id, 2, lane3red)
Ret = DioOutBit(Id, 3, lane4red)

Exit Do
Loop

This is the end of the loop that I want to look for the finished button.

'I want to use a button to set Finished but have not had success at doing that yet.
If Finished Then
Exit Do
End If
Loop
Finished = False

Here is the Start sub

Private Sub _CmdTimer_0_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles _CmdTimer_0.Click

End Sub

Here is the finished sub

Private Sub _CmdTimer_1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles _CmdTimer_1.Click

End Sub

Ow that's confusing. Is that code in the start button event handler _CmdTimer_0_Click()?

Using DoEvents is asking for trouble. I wonder what happens if you press the start button while it's running that loop. Maybe that's what happens? Then you press stop and it only stops one of the loops.

You said you had some timers, how do they fit into it? It looks like it's blasting through the outer loop as fast as it can. That's usually a bad idea if it's not actually doing anything. Could you have it on a timer so it only checks the inputs at each timer tick? That way the application can remain responsive without DoEvents.

the only code in the event handler is the " Private Sub _CmdTimer_0_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles _CmdTimer_0.Click"

End Sub

the DoEvents was the only way that I found to get the program to see the buttons.

this is a very high speed millesecond timer program that must watch for the inputs all the time or they may be missed. I need to do the inner loop at a fast rate but the buttons are not time critical.

I started this program a year ago and have tested the timing portion and every thing worked fine until I added the user interface portion.

Oh it's empty. So how does it know when the button's pressed? That's the "Index" variable??

I wouldn't trust anything not to get delayed for a few milliseconds. Not really what Windows is good at, especially .Net. DoEvents could potentially take control out of the loop for ages too.

Usually high speed data acquisition would involve a buffer in the hardware to allow speed glitches in the PC.

Look at the code tags please, its all explained in the first post in this forum.

If you are processing on the main thread (which you are, a button click) then it will block all other events until it is finished. If you use DoEvents as you have when that line of code is hit, it will allow other events to fire, ie your cancel button. At the end of those event(s) your code will carry on. If you have not checked that you should be stopping, it will just continue on its normal path as though nothing happend. In your case the code after your DoEvents is actually another loop. For a quick fix you could check for the

Code:

---

If Finished Then
  Exit Do
End If

---

part, immediately after the DoEvents line. This will allow you to check for the Cancel button and exit the loop before the inner loop. I can only guess that from your code but I can not see where Finished is being set, assumuing its the cancel button?

Your best method is to use a backgroundworker thread and leave the main thread alone!

As posted there's no inner loop because it always exits before looping. I guess that's another issue.

Yea another thread sounds pretty good. I use that for CPU intensive stuff and it's beautifully seamless and smooth. Only issue that worries me is that millisecond timing. It might get lucky and do it right most of the time, but anything could mess it up.

Can you explain more about the application and its requirements? Is it acceptable for it to cock-up occasionally and ask the user to try again? I almost wonder if a device driver is the ideal answer here, but that's weird and scary! :P

Haha actually you know what would work great is DOS :P Man this would be a really easy and robust application in that case. But no.

Tried the

If Finished Then
Exit Do
End If

Suggestion and the same thing happens!

This program must be very dependable it is going to be used for a four lane snowmobile grass drag timing system. I am using a high speed USB I/O module to read the DC Photo Eyes which was a not an easy task to get working correctly.

would it be easier to send you the whole project even tough you would not be able to actually debug it since you don't have the module.

I have never tried threaded programing I have looked at it but have not figured out how to implement it.

I have written in visual basic many years ago but they have changed so much in .net

Grimfort,

I think you might be on to something. Will this piece of code be exicuted during a DoEvents?

Private Sub Button1_Click_1(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Finished = True
End Sub

This is what I though would set the Finished argument,

If you want the UI to remain responsive while performing other tasks then multi-threading is THE answer. It's for you to now do some reading and then whatever testing is required. If you have create one or more test projects to get the hang of it before trying to implement it in your current project then so be it. I would suggest that a good place to start would be my own CodeBank thread on using the BackgroundWorker, which you can get to via the link in my signature. The idea of the BackgroundWorker is to make multi-threading simple by making it appear just like any other code, i.e. you call methods and handle events and that's it. The only thing you have to remember is that you must NOT access any controls directly in the DoWork event handler. If you have any specific questions on using the BackgroundWorker then you can post a new thread. Once you're confident with the class then you can use it in your current project.

Could the USB module include time data with its output? Since it's meant to be high speed I'd imagine it comes with some facility like that. If you can do that then you can just poll for data as slow as the UI needs to be updated.

Otherwise, yea, you pretty much need another thread. Then when events are fired for all manner of reasons, it should still be able to keep your code running while those events are being handled. Unlike DoEvents which stops to handle them all. Still it's not guaranteed, Windows isn't a real-time OS so you can never be sure how fast applications will run.