Update in GDBG

Hi Clay, I remember you mentioning that in GDBG only visible rows gets updated.. even though there could be a update in the underlying rows that are out of user sight.. For example i tried placing a GDBG and there are 100 rows but i am updating the last 10 rows.. whereas to the user only first 10 rows are visible.. i see cpu usage shooting upto 35% it means GDBG is trying to update the grid..

Clay, this looks like a bug to me because i have Binder.Suspendbinding before update and resumebinding after update.. What is happening is if i say resumebinding it paints the entire grid.. added a event handler in prepareviewstyleinfo to verify and i do see all column getting painted even though updates are happening on bottom most rows..when i remove the suspend and resume binding code.. everything works fine...i am going to try in the real app.. hopefully should get a boost >Hi Clay, > >I remember you mentioning that in GDBG only visible rows gets updated.. even though there could be a update in the underlying rows that are out of user sight.. For example i tried placing a GDBG and there are 100 rows but i am updating the last 10 rows.. whereas to the user only first 10 rows are visible.. i see cpu usage shooting upto 35% it means GDBG is trying to update the grid.. > >

Is the DataTable sorted and the sorted column one of the ones that can change? If so, then the underlying dataview raises a ListChangedType.Reset ListChanged event when a sorted value is changed. In this case, the grid is forced to reset because of the ListChangedType.Reset event. Here is a sample that shows that PrepareViewStyleInfo is not hit when the updates are off teh screen. All the updates are below row 60. If you scroll down so these rows are visible you will see Console.WriteLine output in the Output windows from PrepareViewStyleInfo being hit. But if you let the grid be such that these rows are not visible, there is no PrepareViewStyleInfo hit (unless you are moving your mouse over the grid in whcih case it is hit). http://www.syncfusion.com/Support/user/uploads/GDBG_Updating_a79de18f.zip

Clay.. Apology for not being clear.. i have modified the code private void t_Tick(object sender, EventArgs e) { gridDataBoundGrid1.Binder.SuspendBinding(); this.dt.Rows[row].BeginEdit(); this.dt.Rows[row][2] = val.ToString(); this.dt.Rows[row].EndEdit(); row = (row + 1) % 40 + 60; val++; gridDataBoundGrid1.Binder.ResumeBinding(); } now run the sample .. u shud see the entire grid updating.. as a recommended practice we always do suspend and resume binding when we receive bulk updates.. >Is the DataTable sorted and the sorted column one of the ones that can change? If so, then the underlying dataview raises a ListChangedType.Reset ListChanged event when a sorted value is changed. In this case, the grid is forced to reset because of the ListChangedType.Reset event. > >Here is a sample that shows that PrepareViewStyleInfo is not hit when the updates are off teh screen. All the updates are below row 60. If you scroll down so these rows are visible you will see Console.WriteLine output in the Output windows from PrepareViewStyleInfo being hit. But if you let the grid be such that these rows are not visible, there is no PrepareViewStyleInfo hit (unless you are moving your mouse over the grid in whcih case it is hit). > >http://www.syncfusion.com/Support/user/uploads/GDBG_Updating_a79de18f.zip > > > >

I will discuss this with Stefan to see if he thinks this is something he can avoid when using grid.SuspendBinding/ResumeBinding. You can suspend the binding on the currencymanager while you update and avoid hitting the PrepareViewStyleInfo. BindingManagerBase bmb = this.gridDataBoundGrid1.BindingContext[this.gridDataBoundGrid1.DataSource, this.gridDataBoundGrid1.DataMember]; bmb.SuspendBinding(); //.... bmb.ResumeBinding();