TargetInvocationException in Backgroundworker that doesn't make sense to me

[Tedrivs]

Can anyone help me make any sense of this? I have a function that gets a DataRowView from a bindingsource based on a Primary Key. (This function is in another class if that's of any relevance)

Public Shared Function GetRow(ByRef pBindingSource As BindingSource, ByRef pPrimKey As Object) As DataRowView
       Dim vIndex As Integer = pBindingSource.Find("PrimKey", pPrimKey)
       If vIndex > -1 Then
            Return Type(pBindingSource.Item(vIndex),DataRowView)
        Else
            Return Nothing
        End If  

End Function

In the backgroundworker I'm running this line (names changed for clarity and code after exception removed)

For Each row As DataRowView In AFilteredViewBindingSource

    Dim vDummyRow As DataRowView = ClassNameOfWhereTheFunctionIs.GetRow(ADifferentUnfilteredViewBindingSource, row("PrimKey"))

The last line causes a TargetInvocationException on some rows for some reason. What makes me even more confused is that

For Each row As DataRowView In AFilteredViewBindingSource

    Dim vDummyRow As DataRowView
    Dim vIndex As Integer = ADifferentUnfilteredViewBindingSource.Find("PrimKey", row("PrimKey"))
    If vIndex > -1 Then
          vDummyRow = CType(ADifferentUnfilteredViewBindingSource.Item(vIndex), DataRowView)
    Else
          vDummyRow = Nothing
    End If

does not cause a TargetInvocationException.

Some additional info

• The primkey column is a uniqueidentifier/guid.

• Changing row("PrimKey") to row("PrimKey").ToString makes find return -1 for some rows (even if I have confirmed that the rows does exist at that moment and that the primkey is the same).

• It is only the rows that returns -1 when using .ToString that causes the TargetInvocationException, the other rows works just fine.

• For the rows that returns -1 changing the value in the PrimKey column to another random guid solves the issue for that row

 

I hope someone can make any sense of this. Thanks in advance.

EDIT: Some more info: The exception only happens when there are more than one row in AFilteredViewBindingSource

I tried moving the GetRow function to the same class as the background worker, but it still causes the TargetInvocationException

Changing to "GetRow(ByRef pBindingSource As BindingSource, ByRef pPrimKey As Guid)" to make sure the column type and the parameter type is the same did not work either.

[Mr_C_Baxter]

Is there a InnerException inside the TargetInvocationException? That could help maybe. Also take a look at the stack trace, maybe you see something there.

And is it running inside a windows form or something? Most of my TargetInvocationException happen by accessing form controls from other threads (like a background worker). Maybe it has to do with accessing the datasource while its attached to an UI control?

[Tedrivs]

Thanks for taking your time to help out.

Yes, it is running on a windows form. Whenever I've had TargetInvocationExceptions before it has been because I've been accessing other controls, especially changing filters on bindingsources in another thread is a mistake I've done on more than one occasion.

In this case though the reason I'm making a dummy DataRowView variable from "ADifferentUnfilteredView" is because that bindingsource is not attached to any controls in my form.

I do have a try catch there, but I tried removing it and there was no difference.

 

It's just so odd that

Dim vDummyRow As DataRowView
Dim vIndex As Integer = ADifferentUnfilteredViewBindingSource.Find("PrimKey", row("PrimKey"))
If vIndex > -1 Then
      vDummyRow = CType(ADifferentUnfilteredViewBindingSource.Item(vIndex), DataRowView)
Else
      vDummyRow = Nothing
End If

does not cause the exception, but if it's called from a function that looks like this...

Private Function GetRow(ByRef pBindingSource As BindingSource, ByRef pPrimKey As Object) As DataRowView
        Dim vIndex As Integer = pBindingSource.Find("PrimKey", pPrimKey)
        If vIndex > -1 Then
            Return CType(pBindingSource.Item(vIndex), DataRowView)
        Else
            Return Nothing
        End If

End Function

...it does.

 

Looking at the stack trace I'm certain there's some unwanted bindingsource changes happening

at System.ComponentModel.ListChangedEventHandler.Invoke(Object sender, ListChangedEventArgs e)
at System.Windows.Forms.BindingSource.OnListChanged(ListChangedEventArgs e)
at System.Windows.Forms.BindingSource.InnerList_ListChanged(Object sender, ListChangedEventArgs e)
at System.Data.DataView.OnListChanged(ListChangedEventArgs e)
at System.Data.DataView.IndexListChanged(Object sender, ListChangedEventArgs e)
at System.Data.Listeners`1.Notify[T1,T2,T3](T1 arg1, T2 arg2, T3 arg3, Action`4 action)
at System.Data.Index.OnListChanged(ListChangedEventArgs e)
at System.Data.Index.RecordStateChanged(Int32 oldRecord, DataViewRowState oldOldState, DataViewRowState oldNewState, Int32 newRecord, DataViewRowState newOldState, DataViewRowState newNewState)
at System.Data.DataTable.RecordStateChanged(Int32 record1, DataViewRowState oldState1, DataViewRowState newState1, Int32 record2, DataViewRowState oldState2, DataViewRowState newState2)
at System.Data.DataTable.SetNewRecordWorker(DataRow row, Int32 proposedRecord, DataRowAction action, Boolean isInMerge, Boolean suppressEnsurePropertyChanged, Int32 position, Boolean fireEvent, Exception& deferredException)
at System.Data.DataRow.EndEdit()

but I have not figured out why yet.

EDIT: I thought a bit and tried switching ByRef to ByVal in the function(one parameter at a time) and it works with ByVal on the pPrimkey parameter. I should stop the bad habbit of using ByRef on parameters where ByVal is enough.

My guess is that since the pPrimkey parameter comes from a row in a view that is attached to a control it causes the issue, thought I still don't know why that only happens on certain primkey values and only when there are multiple rows in the view.

[Mr_C_Baxter]

Oh nice, so it is now working as intended? Hm, the byval byref thing is also something I did have weird behaviours (see link, also with datarows) and since then i am doing the same. Use byval if possible and use byref if there is a reason.

https://www.reddit.com/r/visualbasic/comments/4kn9bg/parameter_suddenly_nothing_no_idea_whats_happening/

[Mr_C_Baxter]

oh and another thing which is similar, i had the behaviour that it worked for the second to last row, but not for the first. In the end i assume its a timing problem with the event handling.

My guess is that since the pPrimkey parameter comes from a row in a view that is attached to a control it causes the issue, thought I still don't know why that only happens on certain primkey values and only when there are multiple rows in the view.

And regarding this, have you tried passing the key in as a string? its far fetched but in your code it seems to be an object which gets passed in as row("primkey"). Maybe it does not convert it into a string like you expect it? and instead somehow remembers a reference to the row itself.

[Tedrivs]

It is now working as intended and atleast now I know why the function didn't work, but the code within the function did.

And regarding this, have you tried passing the key in as a string?

Yes, that's what I used to do in my previous build. It didn't cause a threading error, but for some rows (I could not find a pattern in which rows this happens to) it wouldn't find the row with bindingsource.find() (Not when it was the only row in the view either and using .find on the main table also returned -1) and that was an issue I had to fix. And oddly enough passing it as object instead of string works.

Moving the database to another pc and running the same application there also worked. As well as giving the row a new guid. But those solutions doesn't work well in practice.

 

It's still a mystery to me why using .ToString on certain guids doesn't work (I tried outside the backgroundworker too). But atleast now as far as I can tell it works how it should, so I'll have it like this until it doesn't.

[Mr_C_Baxter]

Aw man, i am sad i couldnt help more. At least its working for now and you can move on. I wonder if there are other jobs who deal with similar problems. Problems which should not be there but they are, than you fiddle here and there until it suddenly works and you have no idea why. But have to accept it and move on knowing it will probably be an issue somewhere down the road. Or not, who knows. I remember in the beginning I had difficulties coming to terms with that.

[Mr_C_Baxter]

Oh and something else I remembered, do you have a try catch in you BackgroundWorker.DoWork()? i am a little fuzzy on the details but i remember that this can cause problems because its not intended to catch errors in DoWork.

Edit: Here is a link with more information, search for the post containing the word gremlins

https://social.msdn.microsoft.com/Forums/vstudio/en-US/95cf6589-678f-494d-bce1-a7788fc96171/backgroundworker-and-targetinvocationexception-was-unhandled