But if you concentrate on the TableView1.ScrollTo event, I think it is the origin of the infinite loop.
The issue is actually cmbStudentID_ValueChanged. The offending line is the following
If TableView1.SelectedRow = -1 Or TableView1.SelectedRowValues(0) <> Value Then
Here is how it plays out:
1) Push down arrow
2) TableView1_SelectedRowChanged is called
a) cmbStudendID.Value is changed (if Index is not -1) and triggers the ValueChanged event
3) cmbStudentID_ValueChanged is called with the new value given in step #2. For our purposes, it is ID#2
a) A Wait For is used to load the student information given the value passed on to cmbStudentID_ValueChanged (ID#3)
*** This is the part the causes the issue. The Wait For allows for the processing of new events/queued events (therefor making the UI responsive).
4) Before 3a finishes, another down arrow is pressed which causes another ValueChanged event to fire
5) cmbStudentID_ValueChanged is called with the new value given in step #2. For our purposes, it is ID#3
a) A Wait For is used to load the student information given the value passed on to cmbStudentID_ValueChanged (ID#3)
3) continues
b) Wait For "select_tests"
5) continues
b) Wait For "select_tests"
3) continues
c) Wait For FindFailedTests
5) continues
c) Wait For FindFailedTests
3) continues - Here is where it all falls down
d)
If TableView1.SelectedRow = -1 Or TableView1.SelectedRowValues(0) <> Value Then
If you use the cursor keys or click on a record with the mouse, SelectedRowValues(0) should be the same as Value and everything should just work as is (the IF statement block should be skipped). But, because Wait For allowed for processing of events and because of #4, the following happens:
SelectedRowValues(0) = ID#3 (the highlighted record) and not equal to ID#2 (as passed to Step 3 of the cmbStudentID_ValueChanged call). Therefore, we process the if statement which changes the SelectedRowValues to those of the row ID#2 and changes the highlight back to the TableView1 item with the ID#2 using ScrollTo, triggering an event for
6) TableView1_SelectedRowChanged is called
a) cmbStudendID.Value is changed (if Index is not -1) and triggers the ValueChanged event. The value is ID#2
5) continues - let's start some looping
d)
If TableView1.SelectedRow = -1 Or TableView1.SelectedRowValues(0) <> Value Then
Because of 3d), SelectedRowValues(0) is ID#2, which is not equal to ID#3. Therefore we process the IF statement, changing SelectedRowValues to those of row id#3. ScrollTo is called to change the highlight back to the TableView1 item with ID#3, triggering an event for
7) TableView1_SelectedRowChanged is called
a) cmbStudendID.Value is changed (if Index is not -1) and triggers the ValueChanged event. The value id ID#3
8) a) Repeat 3a
9) a) Repeat 5a
8) b) Repeat 3b
9) b) Repeat 5b
etc...
Casually using the up and down arrow keys does not trigger this, but holding down the arrow keys (either up or down) will and it does not matter if you are hitting the beginning or the end. And it is usually a little bit more complicated since the rapid key presses allowes for 3,4,or 5 differend ID's to bounce back and forth between each other. What a mess.
2 solutions that I tried that did not solve the issue (before realizing exactly what is happening):
1) Using a busyFlag (did not solve the issue)
2) Enabling/Disabling the TableView (bad).
The final solution that worked:
Before calling the first Wait For in the cmbStudentID_ValueChanged method do
Dim selectedRow As Int = TableView1.SelectedRow
Dim selectedRowValue As Object = TableView1.SelectedRowValues(0)
and change the IF statement to
If selectedRow = -1 Or selectedRowValue <> Value Then
This way we isolate the method from changes to the underlying TableView1 class that can happen by events that happen during Wait For and can properly process (in this case, skip processing) the table record highlighting.
Updated code attached in Post#1
P.S.: Hope this made some sense
