Reputation: 4467
Here is my scenario.
I have the following line of code in my program:
JCL_History.Enqueue(JCL_History(I))
This JCL_History object is basically a Generic.List encapsulated in a wrapper and has the following method:
Public Sub Enqueue(ByRef value As String)
If Members.Contains(value) Then
Me.RemoveAt(Members.IndexOf(value))
ElseIf _Count = _MaxCount Then
Me.RemoveAt(_Count - 1)
End If
Me.Insert(0, value)
End Sub
So you see that the first line of code that invokes Enqueue should "shuffle" items around.
Also, the wrapper class of which JCL_History is a type has the following default property:
Default Public Property Item(ByVal Index As Integer) As String 'Implements Generic.IList(Of String).Item
Get
If Index < _MaxCount Then
Return Members(Index)
Else
Throw New IndexOutOfRangeException("Bug encountered while accessing job command file history, please send an error report.")
End If
End Get
Set(ByVal value As String)
If Index < _MaxCount Then
If Index = _Count Then _Count = _Count + 1
Members(Index) = value
Else
Throw New IndexOutOfRangeException("Bug encountered while accessing job command file history, please send an error report.")
End If
End Set
End Property
In my testing I have 2 items in this JCL_History list. When I call that first line of code I posted (the one that invokes Enqueue) with I = 1 I expect the first item to be shuffled to the bottom and the second item to be shuffled to the top.
After the thread returns from Enqueue I notice that this is exactly what happens to my list, HOWEVER if I hit the "step_in" button after the execution of Enqueue I go into the Default Property's set method where Index = 1 and value = and it screws everything up, because the item that got shuffled to the end (index 1) gets overwritten by the item value shuffled to the top.
So basically the set method on the default property is getting called at what I think to be a completely ridiculous time. What gives? By the way I'm running VS2005 on XP.
Upvotes: 1
Views: 320
Reputation: 1633
Do you have a watch and/or are you executing a quick watch via a mouse-over that would read a property that might invoke the Set? If your debugging environment evaluates something that changes data, you can get weird behavior like what you're describing.
Whether or not the case above is true, if multiple threads can write to Members, consider using ReaderWriterLockSlim.
Upvotes: 1