Goran
Wed Mar 02 20:35:05 CST 2005
Did anybody ever get a resolution to this problem? We are dealing with the
same problem.
Thanks
"Angel Saenz-Badillos[MS]" wrote:
> Urs,
> I have sent another email, hopefully he can contact you shortly.
>
> Thanks,
> --
> Angel Saenz-Badillos [MS] Managed Providers
> This posting is provided "AS IS", with no warranties, and confers no
> rights.Please do not send email directly to this alias.
> This alias is for newsgroup purposes only.
> I am now blogging about ADO.NET:
http://weblogs.asp.net/angelsb/
>
>
>
>
> "Urs Eichmann" <Urs Eichmann@discussions.microsoft.com> wrote in message
> news:277179B1-0303-47B9-9A35-9503BE117B02@microsoft.com...
> > Hi, didn't hear anything vom Ravi or anyone from MS regarding this issue.
> > We're currently blocked with our App...
> >
> > Urs
> >
> >
> > "Angel Saenz-Badillos[MS]" wrote:
> >
> > > Urs,
> > > I have pointed Ravi from the dataset team to this thread, hopefully he
> will
> > > be able to help.
> > >
> > > --
> > > Angel Saenz-Badillos [MS] Managed Providers
> > > This posting is provided "AS IS", with no warranties, and confers no
> > > rights.Please do not send email directly to this alias.
> > > This alias is for newsgroup purposes only.
> > > I am now blogging about ADO.NET:
http://weblogs.asp.net/angelsb/
> > >
> > >
> > >
> > >
> > > "Urs Eichmann" <xx@yy.ch> wrote in message
> > > news:uenatwimEHA.648@tk2msftngp13.phx.gbl...
> > > > Angel,
> > > > I don't agree with this answer, for these reasons:
> > > >
> > > > a) the event occurs on the *same* thread as the main program, so it is
> > > > *not* a multi-threading problem (you can see for yourself if you watch
> > > > it in the debugger). So using "Invoke" won't make any difference IMHO.
> > > >
> > > > b) It is *not* documented anywhere that "write" operations in an
> > > > EventHandler are not supported (at least I couldn't find this in the
> docs)
> > > >
> > > > c) This code ran fine *without* SP1, in fact even back with .NET 1.0
> > > > there was no problem.
> > > >
> > > > d) I couldn't find any hint in the SP1 docs that there are
> > > > incompatiblities to be expected in the DataView class between RTM and
> SP1.
> > > >
> > > > I modified the repro program so that the event doesn't add a new row,
> > > > but changes the one just added. This is quite a common scenario: Apply
> > > > calculated values into certain columns of a new row which the user
> just
> > > > entered. This worked with pre-SP1 releases, but no longer works now. I
> > > > think this is a serious thing which shouldn't be taken on the light
> > > > shoulder. At least there should be a KB article which explains a
> > > workaround.
> > > >
> > > > -------- Start Repro -----
> > > >
> > > > Imports System.Data
> > > >
> > > > Module Module1
> > > >
> > > > Private dt As DataTable
> > > > Private dv, dv2 As DataView
> > > >
> > > > Sub Main()
> > > >
> > > > dt = New System.Data.DataTable
> > > > dt.Columns.Add("Col1", GetType(String))
> > > > dt.Columns.Add("Col2", GetType(String))
> > > >
> > > > dv = New DataView(dt, "", "Col1",
> DataViewRowState.CurrentRows)
> > > > AddHandler dv.ListChanged, AddressOf OnListchanged
> > > >
> > > > ' The program only fails if there is more than one View, so
> > > > create a second one
> > > > dv2 = New DataView(dt, "", "Col2",
> DataViewRowState.CurrentRows)
> > > >
> > > > dt.Rows.Add(New Object() {"a", "b"}) ' NullReferenceExeption
> > > > occurs here
> > > >
> > > > End Sub
> > > >
> > > > Private Sub X()
> > > >
> > > > End Sub
> > > >
> > > > Private Sub OnListchanged(ByVal s As Object, ByVal e As
> > > > System.ComponentModel.ListChangedEventArgs)
> > > >
> > > > Static recusive As Boolean
> > > > If recusive Then Return
> > > > recusive = True
> > > >
> > > > ' Modify the row which was just added
> > > > Dim r As DataRowView = dv.Item(e.NewIndex)
> > > > r.BeginEdit()
> > > > r("Col2") = "xxx"
> > > > r.EndEdit()
> > > >
> > > > End Sub
> > > >
> > > > End Module
> > > >
> > > > ---- End Repro ---------
> > > >
> > > >
> > > > Best regards,
> > > > Urs
> > > >
> > > >
> > > > Angel Saenz-Badillos[MS] wrote:
> > > > > Uris,
> > > > > This is the response that I got from the dataset team:
> > > > > "This is an unsupported scenario. Any "write" operations on DataSet
> in
> > > an
> > > > > event handler will result in an unpredictable behavior.
> > > > > I'd suggest an alternative way of solving his scenario."
> > > > >
> > > > > I am not sure of what they mean with alternative solution, but it is
> > > true
> > > > > that "touching" the datatable in multiple threads is not supported.
> You
> > > can
> > > > > probably get arround this limitation by binding on the UI thread
> before
> > > > > calling the Add method with something like this (please excuse the
> code
> > > > > hack, I am doing copy paste from a c# project I had laying arround,
> > > > > hopefully you can get the idea of what to look for from here). The
> basic
> > > > > concept is that you can only call datatable add on the same thread
> in
> > > which
> > > > > you created the datatable, in this case we assume you created it on
> the
> > > main
> > > > > thread.
> > > > >
> > > > >
> > > > > delegate void UICallback( object param );
> > > > >
> > > > > void ReBindOnUIThread( object param )
> > > > > {
> > > > > //This method will run in the main thread, we can touch the
> > > DataTable
> > > > > here:
> > > > > dt.Rows.Add(New Object() {"c", "d"})
> > > > > }
> > > > >
> > > > > Private Sub OnListchanged(ByVal s As Object, ByVal e As
> > > > > System.ComponentModel.ListChangedEventArgs)
> > > > >
> > > > > If b Then Return
> > > > > b = True ' don't want recursive calling
> > > > > //you can't touch the datatable here since we are in a
> > > different
> > > > > thread
> > > > > //dt.Rows.Add(New Object() {"c", "d"})
> > > > > //instead we rebind on the ui thread using the delegate
> > > > > this.Invoke( new UICallback( ReBindOnUIThread ), new
> object[]
> > > {
> > > > > <myobject>} );
> > > > >
> > > > > End Sub
> > > > >
> > >
> > >
> > >
>
>
>