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
My other version of this question never came thru. It must have been "moderated". It had a picture in it.
Anyway, I'm still struggling with XamGrid property : ItemsSource. I wish this was actually a well-documented since it is probably the most important one by far. Does it REALLY support IBindingList? Does it REALLY support DataView? How does it receive collection changed events? Is DataView able to be replaced with BindingSource?
Maybe someone needs to *document* the XamGrid and then support it, or else replace its internal implementation via the more recent XamDataGrid (if that's the one that is supposedly documented/supported). As it is, the XamGrid does *not* reflect very well on your WPF control lineup.
I'm having a great deal of difficulty binding to a BindingSource (IBindingList). It gives the appearance of working but there are subtle issues. For example, certain XamGrid events like "ColumnLayoutAssigned" aren't fired. ColumnLayouts aren't available when you need them. Until I got tired of it, I was able to step thru the code and see that a RowsManager (whatever that is) for a XamGrid isn't creating a DataManager (whatever that is) when the ItemsSource is set to a BindingSource. Whereas a DataManager *is* created successfully (and other important related things happen successfully) when the ItemsSource is set to a DataView.
The whole point of this unsuccessful experiment was to temporarily defer list changed events (IBindingListData_ListChanged) . Obviously using BindingSource is not the way to go about it. Was there another approach I overlooked? Please let me know. Is it worth opening a support incident for this? I've wasted a good day or two already.
Hello dbeavon,
Thank you for your post.
I have been investigating into this issue, and the XamGrid does support binding to BindingSource. In a sample project that I have created, I have bound the XamGrid to a BindingSource element that uses a BindingList as its data source. By doing this, I do not see the behavior that you are referring to, where the RowsManager never creates a DataManager, or the ColumnLayoutAssigned event not firing. This behavior was also very similar when using a DataView as the source for the BindingSource.
I have attached this sample project to this post. This sample is rather simplistic, but I have rather limited experience using BindingSource on this matter. Would it be possible for you to please run this sample on your machine and verify whether or not the behavior shown in the sample is indicative of the same behavior you are seeing? If it isn't, then would it be possible for you to please provide some more detail as to what is happening in your application, or possibly modify this sample to demonstrate this issue you are seeing?
As far as deferring the list changed events go, I believe that the BindingSource may help with this, as I am currently unaware of any functionality that is built into the XamGrid to defer these events. In your original post to this thread, you had mentioned that you were having trouble with the performance of the DataManager. Would it be possible for you to please provide some more information as to what type of performance issues you are seeing? From your most recent post, it sounds like the trouble is with the list changed-related events, which will fire when you either edit your underlying data, or update the XamGrid by editing its cells- whether it be in the UI or programmatically.
Please let me know if you have any other questions or concerns on this matter.
Sincerely,AndrewAssociate DeveloperInfragistics Inc.www.infragistics.com/support
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.
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
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.
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).
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.