How to load 100,000 list view items without application freeze?
-
Eddy Vluggen wrote:
ry scrolling 100k items on my machine, locating the entry with the name "Bla400x". You could finish an entire bottle of Jacks' before you even reached the entries that start with a "B".
:-D honestly, you have to scroll to specific time, and event icons are pretty distinct, and it is very easy to quickly locate minority of error lines with red icons among majority of bluish info events. while scrolling time column is pretty visible as you scroll it. I'm off alcohol :laugh: that enables me to scroll in less than second entire list
Eddy Vluggen wrote:
The difference is that it's merely adding a few items every second, and the user will rarely scroll through all the items to locate a particular entry.
I've just rechecked in Event Viewer events logs, scroll bar is so small that entire list is filled. You can scroll to any place. I do not know it might be some undocumented feature or they are using virtual view.
Eddy Vluggen wrote:
rediculous to assume that you're going to read over 500 results,
I do so always, rather than clicking 50 times to forward to next item, I prefer scroll bar move.
Чесноков
Why not show your design to some users and see what they think of having to scroll through that many items? Get their feedback before you commit to it.
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
-
Chesnokov Yuriy wrote:
Windows Events
Huh? If you're referring to Event Viewer, then yes, I have. And to counter, have you ever looked at ALL of those events, or just the last 100 or so?? Notice how long it takes to populate that list of 1,000 events?? I rest my case. I know it doesn't freeze. That's because it's adding all those events from a background thread, and not all at one time.
A guide to posting questions on CodeProject[^]
Dave KreskowiakDave Kreskowiak wrote:
That's because it's adding all those events from a background thread
Yes, Event Viewer, but scroll bar is height is pretty small. There is impression it is naturally populated. It might be in virtual view or manually driven.
Dave Kreskowiak wrote:
That's because it's adding all those events from a background thread
I do so also. Once you scroll to a middle it displays events in the middle. It'd be rather complicated to simulate the scroll and show only specific items from the middle.
Dave Kreskowiak wrote:
have you ever looked at ALL of those
I did once without problems in PC store when bought a laptop. I had to quickly browse them all to make sure computer was without glitches. I do not have any problems. It is easy just to scroll with a mouse to any particular day and then fine scroll with pgup, pgdwn further :)
Чесноков
-
Thats Easy. just use the listview in virtual mode m8 ;) I have some listviews with over a million entries, and my app dont freeze at all. ;) Just remember to use cached items that also ups the preformance ;) Heres the guideline from MSDN http://msdn.microsoft.com/en-us/library/system.windows.forms.listview.virtualmode.aspx[^] Happy codeing
With great code, comes great complexity, so keep it simple stupid...:-\ :-\
you've the right answer while others complaining they can not handle 1000 lines without a bottle of Jack's :laugh: http://www.codeproject.com/Messages/3753678/Re-How-to-load-100-000-list-view-items-without-app.aspx[^] millions of entries, I could not ever dream of that :) I hope virtual view is not so hard of coding...
Чесноков
-
Eddy Vluggen wrote:
ry scrolling 100k items on my machine, locating the entry with the name "Bla400x". You could finish an entire bottle of Jacks' before you even reached the entries that start with a "B".
:-D honestly, you have to scroll to specific time, and event icons are pretty distinct, and it is very easy to quickly locate minority of error lines with red icons among majority of bluish info events. while scrolling time column is pretty visible as you scroll it. I'm off alcohol :laugh: that enables me to scroll in less than second entire list
Eddy Vluggen wrote:
The difference is that it's merely adding a few items every second, and the user will rarely scroll through all the items to locate a particular entry.
I've just rechecked in Event Viewer events logs, scroll bar is so small that entire list is filled. You can scroll to any place. I do not know it might be some undocumented feature or they are using virtual view.
Eddy Vluggen wrote:
rediculous to assume that you're going to read over 500 results,
I do so always, rather than clicking 50 times to forward to next item, I prefer scroll bar move.
Чесноков
Chesnokov Yuriy wrote:
and event icons are pretty distinct
Not if they scroll by at Mach 2.1 :laugh:
Chesnokov Yuriy wrote:
and it is very easy to quickly locate minority of error lines with red icons among majority of bluish info events
I have a checkbox for that - a single click and all you see are ListView items with a red cross :)
Chesnokov Yuriy wrote:
while scrolling time column is pretty visible as you scroll it. I'm off alcohol Laugh that enables me to scroll in less than second entire list
I don't mind scrolling through the event-log, or the log of the profiler, since I'm expecting a list. I wouldn't recommend the same pattern for database-records representing business-objects. But my apologies, you're right, there are circumstances where it might be appropriate :)
Chesnokov Yuriy wrote:
I've just rechecked in Event Viewer events logs, scroll bar is so small that entire list is filled. You can scroll to any place. I do not know it might be some undocumented feature or they are using virtual view.
It's probably not in .NET. Anyway, there should be a virtual-listview example somewhere on MSDN, give it a try.
Chesnokov Yuriy wrote:
I do so always, rather than clicking 50 times to forward to next item, I prefer scroll bar move.
I prefer hitting
PgDwn, since it takes effort to move my hand from the keyboard and move it to the mouse. Having "pages" to browse through seems to work for a lot of people, especially if there's a nice index at the bottom. Other people prefer a autocomplete-textbox, or indeed, the scrollbar. Do the Microsoft-thing, and implement 'em all! :cool:I are Troll :suss:
-
Eddy Vluggen wrote:
ry scrolling 100k items on my machine, locating the entry with the name "Bla400x". You could finish an entire bottle of Jacks' before you even reached the entries that start with a "B".
:-D honestly, you have to scroll to specific time, and event icons are pretty distinct, and it is very easy to quickly locate minority of error lines with red icons among majority of bluish info events. while scrolling time column is pretty visible as you scroll it. I'm off alcohol :laugh: that enables me to scroll in less than second entire list
Eddy Vluggen wrote:
The difference is that it's merely adding a few items every second, and the user will rarely scroll through all the items to locate a particular entry.
I've just rechecked in Event Viewer events logs, scroll bar is so small that entire list is filled. You can scroll to any place. I do not know it might be some undocumented feature or they are using virtual view.
Eddy Vluggen wrote:
rediculous to assume that you're going to read over 500 results,
I do so always, rather than clicking 50 times to forward to next item, I prefer scroll bar move.
Чесноков
You have been given the same advice from several people now. Why are you continuing to argue the point? If you don't want to use the advice then don't ask for it.
I know the language. I've read a book. - _Madmatt
-
you've the right answer while others complaining they can not handle 1000 lines without a bottle of Jack's :laugh: http://www.codeproject.com/Messages/3753678/Re-How-to-load-100-000-list-view-items-without-app.aspx[^] millions of entries, I could not ever dream of that :) I hope virtual view is not so hard of coding...
Чесноков
Virtual mode is very easy to use and code... just look at the guidline i gave you from microsoft, it shows you the way. But u need to know that virtual mode has its limits, with what it can do, compared to normal mode. ;)
With great code, comes great complexity, so keep it simple stupid...:-\ :-\
-
Didnt see m8, sry ;)
With great code, comes great complexity, so keep it simple stupid...:-\ :-\
-
you've the right answer while others complaining they can not handle 1000 lines without a bottle of Jack's :laugh: http://www.codeproject.com/Messages/3753678/Re-How-to-load-100-000-list-view-items-without-app.aspx[^] millions of entries, I could not ever dream of that :) I hope virtual view is not so hard of coding...
Чесноков
No you missed the point. No one was telling you they couldn't handle it, or that the controls could not support it. They have been telling you it is not a good design. And using the argument that Microsoft does it is not valid. The Event Viewer and such controls are written specifically for high performance situation in C++. You are not doing that are you?
I know the language. I've read a book. - _Madmatt
-
No you missed the point. No one was telling you they couldn't handle it, or that the controls could not support it. They have been telling you it is not a good design. And using the argument that Microsoft does it is not valid. The Event Viewer and such controls are written specifically for high performance situation in C++. You are not doing that are you?
I know the language. I've read a book. - _Madmatt
this entire thread got way too much attention...
do or do not, there is no try
-
It is possible to run addition of items in background worker but it needs to add them in report progress handler, main thread only, which also hangs the application. Is there any other approaches to add them to list view without application freeze?
Чесноков
The common way is to load items which are currently visible (plus some more for a buffer) and continue loading items on demand as user scrolls the list down.
-
It is possible to run addition of items in background worker but it needs to add them in report progress handler, main thread only, which also hangs the application. Is there any other approaches to add them to list view without application freeze?
Чесноков
Preload entries for viewable area and maybe a little around, then load entries only when they should be shown. Cannot specify more concrete, haven't programmed for windows for years. NEVER ever do progress bars for filling controls, this nerves a lot especially if you clicked the wrong control, always use lazy loading. Java AWT is particularly good designed for this approach :)
-
It is possible to run addition of items in background worker but it needs to add them in report progress handler, main thread only, which also hangs the application. Is there any other approaches to add them to list view without application freeze?
Чесноков
I use the telerik winforms suite for similar operations, because it can :laugh: Telerik gridview
-
It is possible to run addition of items in background worker but it needs to add them in report progress handler, main thread only, which also hangs the application. Is there any other approaches to add them to list view without application freeze?
Чесноков
I met the similar problem. Once I wrote a program for retrieving images from a website and I want that users can be notified about the downloading process, so I added a status bar on main GUI, and let the downloading process works on the other thread(let's say B), when it is retrieving the images , the B has to report its status to GUI which is on main thread(let's say A). But B can not access the status bar which belongs to A. So there is a method call BeginInvoke(xxxx); With this method, it enables B to access resourses on A. So I think it should be the answer that you are looking for. Give me reply whatever it works or not :) cheers
-
I met the similar problem. Once I wrote a program for retrieving images from a website and I want that users can be notified about the downloading process, so I added a status bar on main GUI, and let the downloading process works on the other thread(let's say B), when it is retrieving the images , the B has to report its status to GUI which is on main thread(let's say A). But B can not access the status bar which belongs to A. So there is a method call BeginInvoke(xxxx); With this method, it enables B to access resourses on A. So I think it should be the answer that you are looking for. Give me reply whatever it works or not :) cheers
You need to use background worker and report the progress with its ReportProgress() function.
Чесноков
-
Virtual mode is very easy to use and code... just look at the guidline i gave you from microsoft, it shows you the way. But u need to know that virtual mode has its limits, with what it can do, compared to normal mode. ;)
With great code, comes great complexity, so keep it simple stupid...:-\ :-\
Great, thanks, virtual mode is of value to handle large lists especially with large icons. I will use it from now for those purpouses. However I presume I will not be able to use virtual view for log event because the list with those events is not static. There are many threads which use global logger class to report events. They are stored in a queue and once queue limit exceeds some constant 100,000 previous one is dequeued. Log event addition is safe with lock. It is possible that in virtual list view between RetrieveVirtualItem() calls threads may report dozens of new events, queue will move and it will end up of showing the same or odd events several times.
Чесноков
-
this entire thread got way too much attention...
do or do not, there is no try
because the topic is a challenge to display 100,000 in as little time as possible, and to find a user who may process them all :)
Чесноков
-
can you help with dynamic queue for logs? http://www.codeproject.com/Messages/3754435/Re-How-to-load-100-000-list-view-items-without-app.aspx[^]
Чесноков
-
It is possible to run addition of items in background worker but it needs to add them in report progress handler, main thread only, which also hangs the application. Is there any other approaches to add them to list view without application freeze?
Чесноков
Is the code calling BeginUpdate and EndUpdate? It might make a difference, but it's still going to be slow...
-
Is the code calling BeginUpdate and EndUpdate? It might make a difference, but it's still going to be slow...
No, I set the list view Visible to false during events addition. Otherwise the process is very slow.
Чесноков
-
It is possible to run addition of items in background worker but it needs to add them in report progress handler, main thread only, which also hangs the application. Is there any other approaches to add them to list view without application freeze?
Чесноков
Thanks for this question. I have an application with the same problem. The answers by some smart folks here are very helpful in solving this problem.