|
OriginalGriff wrote: How do you find what you want in a list of 100,000 items
There is scroll bar, I can scroll them all easily  and find event I'm looking for.
Filtering is another extension to consider, the problem is to load them all at once.
Why Microsoft can do that and we can't?
Was it the serious desing flaw in windows event viewer or not we may further argue.
OriginalGriff wrote: Does Google load all 10,000 hits into a single page
Perhaps there might be other reasons we may ask google. I presume it may hang IE, firefox or any other browser and induce them to consume all the free mem.
If it hangs IE to load some of the pages with java which fits into a single window, consider what would happen with a page consisted of 10000 links.
Чесноков
|
|
|
|
|
Chesnokov Yuriy wrote: There is scroll bar, I can scroll them all easily
Try 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".
Chesnokov Yuriy wrote: Why Microsoft can do that and we can't?
You're referring to the Spy-program, where a ListBox is used for logging. Microsoft is using the same technique in it's Sql Profiler. 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.
Now, adding text to a collection that's displayed in a control doesn't take much time. Loading a lot of records from your database and adding them to your list will take a lot of time, especially if Windows keeps repainting after each fresh insert.
Chesnokov Yuriy wrote: Perhaps there might be other reasons we may ask google. I presume it may hang IE, firefox or any other browser and induce them to consume all the free mem.
That's far-fetched, your computer won't run out of memory if Google replies with more than 50 results. It would be rediculous to assume that you're going to read over 500 results, so they send you what you're probably going to use. How often did you navigate to the second result-page?
I are Troll 
|
|
|
|
|
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".
 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  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.
|
|
|
|
|
Chesnokov Yuriy wrote: and event icons are pretty distinct
Not if they scroll by at Mach 2.1
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! 
I are Troll
|
|
|
|
|
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
|
|
|
|
|
Mark Nischalke wrote: You have been given the same advice from several people now. Why are you continuing to argue the point?
Déjà vu
|
|
|
|
|
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.
|
|
|
|
|
Dave 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
Чесноков
|
|
|
|
|
I think you have a complete misunderstanding of how event works. Events happen on demand, when you add 100,000 items all at once, you're simply blocking your application message pump from processing the messages sent by windows (also known as events) and therefore freezing.
It's possible to add this 100,000 items in the control without freezing, as already mentioned, by adding in small iteractions and from time to time, allowing the messages to be processed (one simple, but not usually recommended way to do it is call Application.DoEvents()) and thus not freezing the application.
In any case, I agree with the guys that 100,000 items in a listview is simply insane. It doesn't make sense, nobody want's to see 100,000 items all at once. One approach I like to take is to display a couple hundred at once at the most and have a textbox filtering the results as you type, very easy for the user.
|
|
|
|
|
Fabio Franco wrote: think you have a complete misunderstanding of how event works
You do not know my design. Message pump is independent from the view representation, pump observer. There is no blocking of the pump no matter what the observer of the pump do.
The application freeze only at one point, adding of the list view items to list view, either one by one all of them with AddRange.
Fabio Franco wrote: 100,000 items in a listview is simply insane
There are many customers and you can not develop one solution that suit them all.
I'm one of those wierd ones who fond of scrolling 100,000 events 
Чесноков
|
|
|
|
|
Chesnokov Yuriy wrote: You do not know my design. Message pump is independent from the view representation, pump observer. There is no blocking of the pump no matter what the observer of the pump do.
The application freeze only at one point, adding of the list view items to list view, either one by one all of them with AddRange.
It's not your design, the view representation is totally dependant of the message pumb, read my article: FormEx[^] and perhaps you'll have some idea on how the view get's rendered, it's through windows messages. The application freezes because WM_PAINT message never gets processed by your application because there can be only one UI thread and while you're adding items to your listview, the thread get's dedicated to that alone and has no time to process paint, click and other messages because it's adding the items of the listview, UI operations do not run in parallel. Just do a while(true); on a click of a button and that will also block paint messages and will freeze the app. Add Range and adding one by one are doing the exact same things. AddRange is just to make some operations simpler to the control user. Again, I think you have a complete misunderstanding of how event works.
Chesnokov Yuriy wrote: There are many customers and you can not develop one solution that suit them all.
I'm one of those wierd ones who fond of scrolling 100,000 events Wink
Well, if you're developing this to yourself, I guess there's no harm then, but I really think that's not the best approach if you're developing to a client, I know we can't please them all, but I also know that there are best practices and consolidated designs that pleases the most and I really think your approach is not the most appropriate. But who to know better what your target audience wants but yourself? 
|
|
|
|
|
Dave Kreskowiak wrote: That's because the UI thread has to handle adding those items to the ListView. it cannot be done from another thread because you can only maniplute a control on the thread that created it.
You can, however, add each item tot he ListView, one a few at time, from a background thread, by Invoking a method on the UI thread to add just a few items at a time.
What about using a delegate on the background worker thread? This worked for me.
' Because we run our routine that gets the selected class's properties on a background thread using the
' BackgroundWorker component, we can't update our listview directly using this thread, if we try, we get
' a cross-threading exception; our listview was created on the program's main thread and can't be changed
' directly by our background thread.
' To get round this little problem, we create delegate routines and then call the listview control's
' invoke method which uses the delegated routine to update the listview control on the main thread.
Private Delegate Sub AddItem(ByVal lv As ListView, ByVal lvi As ListViewItem)
Private Shared Sub AddListViewItem(ByVal listViewCtrl As ListView, ByVal lvi As ListViewItem)
listViewCtrl.Items.Add(lvi)
End Sub
listViewCtrl.Invoke(New AddItem(AddressOf AddListViewItem), New Object() {listViewCtrl, lvGroupItem})
I'm too lazy to Google it for you.
|
|
|
|
|
A delegate doesn't get around the thread/control problem. It just sets up a parameter for the Invoke call so the AddItem call gets made on the UI thread and not the background thread.
|
|
|
|
|
Change your design and use VirtualMode[^] to allow fast drawing of the ListView irrespective of where in the view you are positioned.
I must get a clever new signature for 2011.
|
|
|
|
|
ok, I may try that in the end
Чесноков
|
|
|
|
|
Hi,
here are some ideas for you:
1. having thousands of items in any Control does not make for a good user interface.
2. list oriented Controls will relayout and/or repaint themselves after every addition. it is wise to use AddRange rather than Add, and sometimes surround the entire operation with SuspendLayout/ResumeLayout.
3. if obtaining the items takes a while, it often helps to build a collection of items to be added to a list Control in a generic list, then add the list's content to the Control. The former can be performed on any thread, the latter obviously needs to be executed by the main thread.
4. some Controls have a "virtual mode" where one only needs to provide items when they become visible.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code. modified on Monday, January 31, 2011 10:26 AM
|
|
|
|
|
1. log events with time column are easy to scroll
2. I tried to hide listview during items addition and then show it again, that increased performance, I will try yours methods
3. no, it does not, objects are already in the generic list with public methods e.g. time, message, keyword etc... the list view is in details view with columns to each field
4. that is not agreeble compared to 2.
Чесноков
|
|
|
|
|
For logging I recommend a ListBox, it will easily handle thousands of lines per second. See here[^].
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
I need to display log events which are already collected in a generic list.
There are thousands of them, I'd like to explore the limits.
ListBox does not contain columns to show specific fields 
Чесноков
|
|
|
|
|
Luc Pattyn wrote: . it is wise to use AddRange rather than Add, and
It will need to create a list of ListViewItems. Will it be faster than reporting from background worker item by item?
Чесноков
|
|
|
|
|
Luc Pattyn wrote: sometimes surround the entire operation with SuspendLayout/ResumeLayout
that is significantly slower than hiding the control
Чесноков
|
|
|
|
|
|
Which is exactly the answer I gave!
I must get a clever new signature for 2011.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
