I have two grid bound to a data relation like the example in this thread.
But with v18.104.22.168, if we enable the UseListChangedEvent to true then it doesn''t work anymore.
Is it a good idea to enable UseListChangedEvent at all?
ADAdministrator Syncfusion Team April 29, 2004 08:20 PM
Another question about the UseListChangedEvent. After upgraded from 22.214.171.124 to 126.96.36.199 the behaviour for
GridDataBoundGrid.Binder.SuspendBinding and ResumeBinding is different depending on the value on UseListChangedEvent.
When UseListChangedEvent is set to false (the default). After call to Resume binding it doesn''t refresh the grid like it use to do. But when UseListChangedEvent is set to true, it does. However, it breaks the DataRelation behaviour.
ADAdministrator Syncfusion Team April 30, 2004 05:49 AM
Try setting the UseListChangedEvent = true only on the Master grid to see if that will work for you. It seems to work OK in the sample you referred to.
Setting the propery on all the grids in a master-details setup does seem to break things.
You can force a refresh after the ListChangedEvent by setting the this.grid.ForceUpdateAfterListChangedEvent property. (Though you may not need this if you only set the UseListChanged property on teh master grid).
If you want to see the advantange of setting UseListChangedEvent = true;, take a look at the Grid\Samples\DataBound\GridPerf. You do not see a great deal of difference on teh initial load. But removing 300 random rows from 20000 records drops from about 12 seconds to less than half a second on modest hardware using this property.
ADAdministrator Syncfusion Team April 30, 2004 04:51 PM
Thanks for the suggestion but I don''t quite understand what do you mean.
I am using a GridDataBoundGrid and it doesn''t have the ForceUpdateAfterListChangedEvent property with v188.8.131.52. Also the non refresh behaviour is only when UseListChangedEvent = false.
Any other suggestions?
ADAdministrator Syncfusion Team April 30, 2004 05:04 PM
After calling grid.ResumeBinding, you can force an update by calling grid.Refresh().
ADAdministrator Syncfusion Team April 30, 2004 05:49 PM
Thanks for the suggestion Clay.
That''s the workaround I was planning to implement. I was looking for a solution that doesn''t require adding an extra call through out the code base.
ADAdministrator Syncfusion Team May 4, 2004 04:17 PM
Will the ResumeBinding behaviour change in future patches of the Grid? We don''t want to modify all call after ResumeBinding to call refresh only to find out it is also called again by the Grid hence having Refresh called twice.
ADAdministrator Syncfusion Team May 5, 2004 12:01 AM
I do not know what future updates may do for this problem.
But in the first update, 184.108.40.206, there is the new property GridDataBoundGrid.ForceUpdateAfterListChangedEvent. So, this *MAY* have an effect. If this update is not available to you by the end of the week, if you send me a sample project showing the problem, I can try it with this property to see if it handles it for you.
If not, and you do not want to do a FindInFiles in your code later to change things if it turns out that this issue is addressed in a future release, then I would derive the grid, add a method that wraps the two calls, and then call this new method everywhere. Then you only have to change the code in a single place.
ADAdministrator Syncfusion Team May 5, 2004 04:53 AM
Thanks Clay, will wait for 220.127.116.11
ADAdministrator Syncfusion Team May 9, 2004 05:07 PM
Tried 18.104.22.168. We''ve come to the conclusion that we pretty much have to switch on UseListChangedEvent in order for the grid to refresh properly after ResumeBinding. We have other issue that refresh can''t fix, particularly on hier grid.
With the master-details problem, will it be fixed soon so that it will work on grid with UseListChangedEvent = true?
ADAdministrator Syncfusion Team May 10, 2004 09:14 AM
I don''t know of a definite time frame for this problem to be addressed. It did not make the first patch, 22.214.171.124. We will try to get it in the next one.