In our current WinForms app, we are displaying millions of records in ListView, using virtualization. Rows are loaded from DB as they are requested. This works well, with good performance.
This is a showstopper for migrating to WPF for us. We need data virtualization in a ListView, like WinForms 2.0 has.
Do you know a decent third-party control, or a relatively easy way of doing it with built-in controls? It doesn't need to be a DataGrid, a simple ListView will suffice.
Note, I'm note talking about UI virtualization, it's data virtualization.
The article WPF Data Virtualization should be exactly what you are looking for, I just implemented it quite easily, and it works.
Xceed DataGrid for WPF has data virtualization support.
This is the description for the Ultimate ListBox for WPF from Xceed:
Intelligent virtualized background data retrieval:
Automatic data retrieval only gets records from the remote data source if they are visible (data virtualization). This greatly reduces the amount of data to be transferred, which increases the perceived speed of the listbox. Also reduces strain on the server.
Just add following properties in your listview declaration in XAML.
<ListView
VirtualizingPanel.IsVirtualizing="True"
VirtualizingPanel.IsVirtualizingWhenGrouping="True"
VirtualizingPanel.VirtualizationMode="Recycling"
ScrollViewer.IsDeferredScrollingEnabled="True" >
</ListView>
Related
am a newbie in the WPF and more so the WPF Datagrid arena. Am so used to working with the cousin -- DatagridView from Windows Forms, but it's my first time working with WPF's Datagrid Control, and am having a very hard time!
I have created a dataset using the in-built datasource wizard in Vidual Studio 2010. After creating this dataset, I used another in-built feature that allows me to auto-generate a datagrid that is pre-bound to this a table in the dataset, so I can just drop it onto the window.
Now, all that is done nicely, til I come to the part where I need to have the user edit the contents of the datagrid, and via a callback, have the new / updated data committed to the underlying table in the database.
I've tried searching around, but most articles are out-dated, and some don't hit the problem in ways that make sense to a newbie like me.
One source says:
DataGrid checks for
IEditableCollectionView’s CanAddNew,
CanCancelEdit, and CanRemove
properties before executing the
EditItem, CancelEdit, or CommitEdit
methods. So if editing appears to not
work for some reason, be sure to check
that it is able to edit.
from an MSDN source, but the Auto-generation feature of Visual Studio 11 gives me this for the data-binding source
<Window.Resources>
<my:crimexDataSet x:Key="crimexDataSet" />
<CollectionViewSource x:Key="datapoolViewSource" Source="{Binding Path=datapool, Source={StaticResource crimexDataSet}}" />
</Window.Resources>
So, how do I move from this to an IEditableCollectionView kind datasource, so I can have editing enabled? Thanks in advance...
If this isn't an application with a short lifetime, I would save myself a lot of pain and learn about the MVVM (Model-View-ViewModel) pattern. It is a very common pattern in the WPF and Silverlight worlds.
Basically, you would make a class specifically designed to be the data source for the grid, and perhaps other data you would need in your window.
For this particular need, you would probably use an ObservableCollection as the type of the property bound to the grid.
There is a lot of information on MVVM here at StackOverflow, to be found on Google, and in books. If you grok the pattern, it can really make the UI development experience a lot less painful.
I have experience in WPF and Windows Forms, however have only used the Windows Forms DataGridView and not the WPF DataGrid (which was only included in .Net 4 or could be added to .Net 3.5 from Codeplex, I understand). I am about to devlop an app using one of these controls heavily for large amounts of data and have read performance is an issue with the WPF DataGrid so I may stick to the Windows Forms DataGridView.. Is this the case?
I do not want to use a 3rd party control.
Does the Windows Forms DataGridView offer significant performance over the WPF DataGrid for large amounts of data?
If I were to use WPF I would prefer to use .Net 3.5S SP1, unless the DataGrid in the .Net 4 is significantly better?
Also I want to use ADO with DataTable's which I feel is better suited to Windows Forms..
For your needs, unless you have other requirements that steer you towards WPF, I would recommend the WinForms DataGridView.
The WPF DataGrid was made available via Codeplex, as an 'out of band' release, i.e. these are control that will eventually make their way into the WPF APIs, but are released on codeplex early so that we can benefit from them before the next major .NET release. You can use either the .NET 4.0 or codeplex DataGrid. As far as I know they are one and the same. The WPF DataGrid plays quite nicely with DataTables. See the examples in my following article:
http://www.codeproject.com/KB/WPF/WPFDataGridExamples.aspx
However, the WPF framework and visuals are slightly more heavyweight than WinForms. Also, the WinForms DataGridView is very mature.
For very large datasets, the WinForms DataGridView has one feature that is not present in the WPF DataGrid, which is vital for very large grids (millions of rows), this is a virtual mode:
http://msdn.microsoft.com/en-us/library/ms171622.aspx
Known also as Data-Virtualization. In this mode, you tell the grid how many rows there are in your data, then handle events to populate the cells. This scales very well. I have used this for massive and complex grids.
WPF has UI virtualization which is a form of UI control recycling, but not data virtualization.
Hope that helps.
For any beginners (like me) making this decision, WindowsForms is tremendously easier to use. Of course, there are a lot of other reasons to use WPF that might influence your decision, but if your project is primarily a DataGrid, then WinForms is the way to go.
You can use a DataGrid WPF as a DataGridView if you at first fill ItemsSource of the DataGrid .
MyDataGrid.ItemsSource = MySource;
MyDataGrid.Columns[0].Width = 300;
MyDataGrid.Columns[0].Header = "MyName";
Check Xceed datagrid for WPF which is way better than WPF DataGrid but that is 3rdparty but worth it.
WPF DataGrid much more faster, I think. But when I try to use WPF DataGrid for big amount of data (a lot of columns (about 40-50) and rows) with styles it working slow (horizontal scrolling). DataGrid from 3rd party controls working much better (I use Infragistics XamDataGrid).
Just wondering if anyone knows about what performance is like for the WPF Toolkit DataGrid for inserting rows to the top of the visible area. I know that ListBox and ListView will recreate all new visuals for all of the rows that are pushed down, which is a major impact on performance; I was wondering if the WPF Toolkit DataGrid does the same thing.
WPF Toolkit DataGrid should do 'Virtualization', which is what in Microsoft speak is 'reusing WPF objects' (see for example http://www.ytechie.com/2008/09/disabling-wpf-datagrid-virtualization.html).
I have a window using a WPF ListView/GridView bound to an ObservableCollection. The performance is utterly horrific. The application chokes trying to load 300-400 items and CPU usage spikes each time an item is added/removed/modified. Profiling doesn't reveal anything obvious.
Anyone have any suggestions?
Check these properties out:
VirtualizingStackPanel.IsVirtualizing="True"
VirtualizingStackPanel.VirtualizationMode="Recycling"
ScrollViewer.IsDeferredScrollingEnabled="True"
You need to virtualize your ListView's ItemSource as explained in this article: WPF: Data Virtualization on CodeProject by Paul McClean
First guess, are you making use of complex data templates for each ListViewItem? This might be anything from lots of images, to (old) BitmapEffects, to even lazy-loaded properties that fetch data on demand from a database (which may cause you to perform many db calls to render each visual, depending on how your data model works).
Second guess, is the list itself able to run its load/add/modified/removed routines quickly (meaning the problem occurs when rendering the data), or does the list itself do those jobs slowly (indicating the list is having some kind of issue).
have you tried virtualization as recommended in this question??
WPF ListView Very Slow Performance - Why? (ElementHost, or Other Reason?)
And the obvious one, make sure you have upgraded to .net 3.5 SP1, there were a lot of performance gains there.
Also it may be worth looking into the WPF datagridview control as a lot of the performance work in .net 3.5 SP1 were so the datagridview would have good performance on large datasets.
http://wpf.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=25047
I had similar problems. Setting MaxHeight to a value larger than the ListView's actual height solved it instantly for me, thanks to this answer here, but I still fail to understand how it worked.
I have seen a lot of discussions going on and people asking about DataGrid for WPF and complaining about Microsoft for not having one with their WPF framework till date. We know that WPF is a great UI technology and have the Concept of ItemsControl,DataTemplate, etc,etc to make great UX. Even WPF has got a more closely matching control- ListView, which can be easily templated to give better UX than a traditional Datagrid like display. And I would say a readymade DataGrid control will kill or hide a lot of creativity and it surely will decrease the innovations in User Experience field.
So what is your opinion about the need of DataGrid in WPF as a Framework component? If you feel it is necessary then is it just because the world is so used to the DatGrid way of data display for many years?
Some other threads having the discussion about DatGrid are here and here
Link to WPF ToolKit - Latest WPF DatGrid
DataGrids are excellent for displaying large amounts of tabular data bound to a backing store.
But what happened in the WinForms world was that people often used them for everything that required a multi-element scrolling list. Souped-up third-party DataGrids soon became available that allowed columns and fields to contain buttons and ComboBoxes and icons, etc.
The DataGrid became a workhorse because there was a need for something it could be coaxed into behaving like. Similar happened to DataTables before generic collections came along--and when you're using lots of DataTables, presenting it in the UI with a DataGrid is the path of least resistance.
I think that when WPF came out, a lot of programmers like me were still thinking in this fashion, and sought out WPF ports of the DataGrid concept.
Can't think of a better control to display tabular data, especially in business apps where you don't want to reinvent the wheel by templating/developing a (Headered)ItemsControl to make it behave like the good old DGV. I'm sure you saw this.
Nobody is disputing that you can make a DataGrid control in WPF yourself. The same can probably be said about WinForms, although it would be more difficult. I've implemented some functionality with ListView - presenting tabular data is easy, you could even say it's well supported. However, the amount of code, manually written code, needed to make an editing ListView is enormous.
The business applications usually require editing of many tables, and you don't want to be creative, you want to be quick. That's why DataGrid is needed in my opinion.
Yes DataGrids will never go away as essential business UI components. People love their spreadsheets and we want to share in that love!
Note that MS are shipping these extra controls - they have created the WPF Toolkit on CodePlex to provide a fast-turnaround, open-source style of deployment.
It already includes a DataGrid and Calendar.
Yes it is!
Among many other controls that ms failed to deliver. (Datepicker, NumericControl)
MS should first give us the tools to get the job done, that is the least i expect from a programming enviroment with the hype of wpf.
It is essential, but you can achieve nearly the same effect with a ListView that is using a GridView, can't you?
After working with WPF for about 2 years now. I would say that a DataGrid is really just a glorified ListBox (since [almost] everything in WPF is styleless).
One could style a ListBox to take an Entity of some sort and show a "record" control for each entry. Depending on how flexible these are made, they could automatically adjust based on the entity passed.