C#

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".

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.

Eddy Vluggen wrote:

rediculous to assume that you're going to read over 500 results,

Chesnokov Yuriy wrote:

and event icons are pretty distinct

Chesnokov Yuriy wrote:

and it is very easy to quickly locate minority of error lines with red icons among majority of bluish info events

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

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.

Chesnokov Yuriy wrote:

I do so always, rather than clicking 50 times to forward to next item, I prefer scroll bar move.

I are Troll

Mark Nischalke wrote:

You have been given the same advice from several people now. Why are you continuing to argue the point?

Chesnokov Yuriy wrote:

Windows Events

Dave Kreskowiak wrote:

That's because it's adding all those events from a background thread

Dave Kreskowiak wrote:

That's because it's adding all those events from a background thread

Dave Kreskowiak wrote:

have you ever looked at ALL of those

Fabio Franco wrote:

think you have a complete misunderstanding of how event works

Fabio Franco wrote:

100,000 items in a listview is simply insane

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.

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

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.

' 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})

Luc Pattyn wrote:

. it is wise to use AddRange rather than Add, and

Luc Pattyn wrote:

sometimes surround the entire operation with SuspendLayout/ResumeLayout