Tried posting this a while ago and it didn't come thru.... (maybe it got filtered for language content?)
Here is the abbreviated... Having trouble with performance of DataManager.... Hot spot seems to be IBindingListData_ListChanged.... Need to defer list changed events.
Does XamGrid have a mechanism for this? Otherwise it it supported for me to bind a XamGrid to a BindingSource (System.Windows.Forms.BindingSource)?
See http://stackoverflow.com/questions/1132818/deferring-datagridview-update-when-editing-the-underlying-datatable
Hello dbeavon,
Thank you for your response.
It is worth noting that the ItemsSource of the XamGrid and the DataSource of the XamDataGrid expect the same type; that is - IEnumerable. The same goes for the Microsoft built-in DataGrid, and likely the community data grid on codeplex. These objects do not need to directly be of type IEnumerable, though. They only need to be a derivation of the IEnumerable interface. For example, the ICollectionView interface derives from IEnumerable, making derivations of ICollectionView (such as ListCollectionView and BindingListCollectionView) IEnumerables. In the case of the original issue brought up by this forum thread, BindingSource is an IEnumerable as well.
The XamGrid supports any derivation of this IEnumerable interface, and so collection types that do derive from IEnumerable or ICollectionView (including BindingListCollectionView and BindingSource) are officially supported by the XamGrid.
Please let me know if you have any other questions or concerns on this matter.
Sincerely,AndrewAssociate DeveloperInfragistics Inc.www.infragistics.com/support
So I'm hearing that IEnumerables and ICollectionViews are in the "wheelhouse" of the XamGrid and not much else beyond those.
If your official support was *only* for only IEnumerable (and nothing beyond that) it would make the XamGrid the weakest one around because IEnumerables don't even track list changed events (for new and removed items). Obviously the XamGrid works for other collection types beyond IEnumerable, albeit in a way that is not officially supported (as I understand).
The differences we are seeing in the callstack may be simply a matter of compiler optimization. At first I was worried that the XamGrid source code I retrieved was not representative of what was used to generate the compiled versions of the 15.2 WPF assemblies.
Thanks for all your help. I think this issue is the one that finally convinces me to avoid XamGrid in future work (in favor of XamDataGrid, DataGrid, and the community datagrid on codeplex).
First, I am glad that you are able to move forward with BindingListCollectionView on this matter. I can see how the Defer method of that collection type would help you here. Regarding the BindingSource issue, I have been stepping through the source code of the XamGrid, and it appears that the reason that the empty BindingSource isn't firing the ColumnLayoutAssigned event is because the DataManager cannot be created internally, because the type of items inside of the BindingSource cannot be resolved.
A couple of posts ago, you mentioned that you were seeing that the empty BindingSource was getting into the RowManager's EnsureDataManager method, but not into the SetupDataManager method. On my end, I am seeing that the empty BindingSource does get into the RowManager's SetupDataManager method, but it can't get past an if check in it that leads to a call to the RowManager's InitializeData method. The line of code prior to this if statement is a call to DataManagerBase.CreateDataManager, which leads to a call to DataManagerBase.ResolveItemType. This ResolveItemType method returns null, which leads to the CreateDataManager method returning null. Since there is no data manager, the SetupDataManager method cannot continue to the InitializeData method, which is what fires the ColumnLayoutAssigned event. It appears that what is happening here is that with the way that the BindingSource is created, there isn't really a way for the item types to be resolved until items have actually been added, as the internal data source to the BindingSource does have access to the item types that it is meant to hold, and so the SetupDataManager method works for these collections.
Regarding an "official stance" on using certain collections or an ICollectionView with the XamGrid, the only official stance for the ItemsSource of a XamGrid is that you use an item that derives from the IEnumerable interface. There are certain aspects that happen with the ICollectionView derivations that don't happen with others though. An example of this could be filtering and sorting operations, in which the operations are carried out by the ICollectionView directly, rather than by the XamGrid.
Please let me know if there is an official stance on using BindingSource with the XamGrid.
But for now I'm giving up on BindingSource. I'm two days behind. So instead, it appears there is an ICollectionView-based thing called a BindingListCollectionView that can be wrapped around a DataView and serves a similar purpose as a BindingSource. I probably should have avoided BindingSource in the first place (since it was in the Windows Forms namespace).
Anyway, with my new best friend, BindingListCollectionView, it is apparently possible to defer the list events using the Defer() method. This seems to be doing a similar thing as BindingSource.RaiseListChangedEvents = false.
Since I'm now moving forward with BindingListCollectionView, I don't suppose there is an official stance on using ICollectionView with the XamGrid?
Thanks, David
Misfire. So here is what you do.
1- Fire up VS and load solution. This is still based on BindingSource by default.
2-Run the sample
3- Notice that you never get to reach grid1_ColumnLayoutAssigned
4- Notice the debugger output. At the point marked "CHECK IN DEBUGGER", you will not have a RowsManager.DataManager for the grid.
5-Open the viewmodel, find the "Data" member property, and swap from the BindingSource to the DataView.
6- Run the sample again
7-Notice that this time around you DO reach the "ColumnLayoutAssigned" event and you DO initialize a RowsManager.DataManager for the xamgrid.
I think this repro shows that BindingSource is not being treated the same as DataView. I imagine there is an initialization method or property on BindingSource that I can use to make them behave similarly but I haven't found it yet. My real overarching complaint with the XamGrid is that I just don't know which if any is supported : BindingSource, DataView, IBindingList, or whatever because there is no *documentation*. I don't want to spend days and days of my development time trying to bind to something if it isn't likely to work or even be supported to begin with.
Would you please step thru the 15.2 code and tell me why the BindingSource scenario (with no data) seems to get into ...
InfragisticsWPF4.Controls.Grids.XamGrid.v15.2.dll!Infragistics.Controls.Grids.RowsManager.EnsureDataManager()
but not to...
InfragisticsWPF4.Controls.Grids.XamGrid.v15.2.dll!Infragistics.Controls.Grids.RowsManager.SetupDataManager()?
That would be a huge help. I am looking at the source myself but cannot see why they would be treated differently.
(I really appreciate your effort on this to help me. One thing your repro did is to show that there are multiple factors involved in the problem and I thought it was simply a difference between using either a BindingSource or DataView. It turns out that when you actually AddData() in the viewmodel, then the BindingSource starts behaving more like a DataView in that you actually *do* end up reaching the ColumnLayoutAssigned event (and receiving a RowsManager.DataManager). For this reason I'm guessing there is some additional initialization I can use on BindingSource to get them to behave more similar to one another, even if there is no underlying data.)
Please let me know whether or not you can repro this as I described above.