I want to take advantage of the async loading of data since it's possible my users could have latent connections. It is possible they pull back data numbering in the thousands of records and sometimes even more. I don't have a datasource available to me right now that would give me my thousands of records right now. I just want to confirm that a user would be able to see the contents of the grid or listbox while the rest of the dataset loads async in the background. It looks like data virtualization could be an option but the articles I have found have either been trash or based on an older version of SL. Does anyone have any links to and POC or examples of this behavior?
If I enable datapaging on my listbox would the first page of data display on the screen as the rest is being fetched? Or does it only load the data as the user navigates to the next page?
You can take advantage of Data Virtualization,
Make the number of UI elements to be created proportional to what is
visible on screen using VirtualizingStackPanel.IsVirtualizing="True".
Have the framework recycle item containers instead of (re)creating
them each time, by setting
VirtualizingStackPanel.VirtualizationMode="Recycling".
Defer scrolling while the scrollbar is in action by using
ScrollViewer.IsDeferredScrollingEnabled="True". Note that this only
improves perceived performance, by waiting until the user releases
the scrollbar thumb to update the content. However, we will see that
it also improves actual performance in the scenarios described below.
The above text is from the excellent Data Virtualization document by Bea Stollinz, written for WPF but should be adopted in Silverlight too.
You may also take advantage of .NET asynchronous programming model such as the IAsyncResult, TPL and the EAP.
Related
My WPF project has a tabcontrol which hosts multiple datagrid control. Each of the datagrid contains about 1000 rows and users are expected to have more than 10 datagrids open in the same time (with each of them being hosted in different tabpages).
The thing is my application would crash at the 5 - 6th datagrid due to out of memory exception. After hours of research I found out that the only viable way to resolve this issue is to enable UI virtualization. However this is not an option because I need smooth scrolling for my datagrid and enabling UI virtualization would disable smooth scrolling.
Another solution would be to change the scrollunit to pixel instead of item based. This is however also not an option in my case because I am restricted to run the application in .NET Framework 4.0 (the feature is only available in 4.5).
Also I am quite certain that it was the rows that was causing the memory issue because if I run the application without a datagrid I could easily load up to 100s viewmodels.
What I am thinking is would it be possible for me to temporarily dispose controls created in the non-visible tabpages and create them only whenever user navigates to the respective tabpage? Else is there any other way to get around this?
Not using datagrids would help.
While such controls can be convenient to use fact is that they are far from lightweight.
Screen will hold ~30 rows at once so there is no need to pollute memory with thousand of them, having loaded more rows to some dataset can smooth up scrolling as you will be feeding grid with pre-fetched data,
You can even create offline cache in temporary file if data is not changing constantly.
I have this application:
I want to change the marked area when the user is clicked one of the navBarItems (like Microsoft OUTLOOK). I've been doing some research and a lot of people said that I can add several panels and show/hide them when user is clicked a navBarItem. But the area will contain a lot of gridviews and a lot of other controls. I don't know if I want to initialize all of them when application starts because it's gonna be hard on the cpu and memory to keep all the controls running at the same time. And I don't think it's an elegant solution for this kind of situation. But if I choose to initialize controls when user is clicked to corresponding navBarItem, it's gonna be laggy for the user.
What is the best design approach for this situation?
PS: I can use commercial libraries too.
Thank you.
Does not necessarily have to be laggy. If you show the screen first and then populate the data in the background it may not look too bad for the user. Also, once a particular screen is initialized you might keep it in memory so subsequent times user navigates to it it will be faster.
Also, look at what data you are loading into each control. Is some of the data the same? Can you preload some of the data in the background and keep it around?
Do you have a lot of drop down lists? If so, can you prepopulate or cache some of the drop down list data to improve the performance?
Is there one or two of the panels that will be used a large majority of the time? If so you could preload these panels so the user has a better experience for the panels they will most often navigate to.
Background processing to load data will make your code more complex but that is going to be the best way to get good response time from your app.
Here is an example of running a background thread from the UI using Task.
And another one using the BackgroundWorker.
I started with using a TableLayoutPanel, but when I have big tables, they are extremely sluggish. I'm looking for the responsiveness of an HTML table to display my data in.
The only solution I currently have is to have my WinForm write and HTML table, and display it in an embedded browser. This obviously is a huge workaround, and I'd rather implement a more clean and straightforward solution.
If you have any suggestions, please fire away. (a ListView will not work for what I'm trying to do)
What about using a DataGridView, or if you have DevExpress, a XtraGridControl? TableLayoutPanel is designed for laying out controls as far as I know, not for presenting data.
On the other hand, if your data set grows as large that your tables become sluggish, you might want to narrow down your data, e.g. by filtering or by introducing paging, one page only displaying 50 items or so.
Paging as well as filtering, in turn, is supported at least by XtraGrid, not sure about Microsoft's DataGridView.
You definitely need either a grid or a report, depends on what you want.
Highly customizable grid controls (like Infragistics or DevExpress) allow you to make almost any appearance you need. Users will have no idea they look at grid control.
I have a program that loads 10,000 rows into a datagrid and the datagrid can be slow to render/paint and occassionally doesn't display, you can tell it has loaded with data but the grid goes blank. I was thinking of replacing the datagrid with DevExpress XtraGrid, has anyone used this and can I expect it to render/paint quicker?
Thanks
PS This is a win form app, there are probably less than 10,000 rows in reality but safe to say a lot. I suspect we need to use paging maybe?
We use the standard DataGridView with hundreds of thousands of rows and dozens of columns with instantaneous performance, no problems at all. In Virtual Mode. Use Virtual Mode.
http://msdn.microsoft.com/en-us/library/2b177d6d.aspx
First off, make sure you are using Virtual Mode with your GridView
From Data Display Modes in the GridView Control:
The primary use of virtual mode
... is to optimize performance
when interacting with large amounts of
data.
MSDN has a tutorial to get you started...
My first spontaneous thought is that it doesn't matter which grid is faster, since 10000 rows in a grid in a user interface feels like an error in itself. But then again I don't know what the application does so it may make sense in the context in which is it used...
Anyone that is looking for a good alternative to the standard datagrid should give SourceGrid a try, it is free and quite well done.
I'm fairly certain that you won't notice a significant improvement by switching. I think the problem is the sheer amount of data you are pushing into the grid (and thus down to the browser).
Can you page this data, or do all 10000 rows have to be on a page? If its the latter, I would consider using a repeater control. If paging is an option, I would suggest pushing the paging back to the data source.
Either should garner you a decent improvement.
3rd party grids can make ajax updates and db-side paging easier, but there is a big learning curve with each one, and formulating the right query isn't that hard if you want to do it in plain old .net.
I'm writing an application that needs a log-like view, (similar to how an IM client displays messages in the conversation), with potentially many updates per second. Speed is an issue here; the application locking up due to a large number of incoming events is a possible problem. I need selection and basic text formatting, so manual rendering could get quite complex, I'd like to avoid it if possible. I'd also like to bottom-anchor the scroll bar, that is, if it's at the bottom, stay at the bottom when the new item is added. What would be a good way to implement this?
You can implement it very easily in WPF.
Create an ObservableCollection of Log entities and bind to a ListBox.
Give a DataTemplate for the ListBox.ItemTemplate.
*When running in real time you need either UI side or Data side virtualization
Check out my PaginatedObservableCollection so that the DataVirtualization will automatically function.
I think you should have a look at ListView/ListBox controls, they support UI virtualization and provide functionality you're looking for. Also you can improve performance by data virtualization/lazy loading - i.e. don't hold invisible items in memory and load required data on demand