Hi, i have currently a performance problems with UltraListView which should show a folder content with big number of files.
My idea was to create items first with name and default icon only. Then get the subitem values and right thumbnail later if the item gets visible.
I haven't found an event like "ItemVisibleChanged" or alike. Is it possible somehow else, may be with creation filter?
Thank you
It would probably be better if you could provide more details on the performance problem; if there's a bug causing it, we would probably want to fix that.
Note that when dealing with large numbers of items, the best way to populate the control's Items collection is to first populate an array, and then use the UltraListView.Items.AddRange method. Because the control has a lot of housekeeping to do when you use the Add method, performance can be orders of magnitude better in some cases when you use AddRange instead.
Also note that there is a sample (might be in the legacy samples now) called Infragistics File Explorer, which features this control, and demonstrates how to emulate the Windows File Explorer using the UltraListView control.
Thank you for the fast answer.
No, I don't think there is a bug in UltraListView control. Seems one of my collegues has adopted your File Explorer sample in some weird manner. The items are already initialized as an array and added with AddRange. But the most time was wasted for getting file icons and SHGetFileInfo calls. We also getting some additional infos from DB for the file items. And that all was for all items once in UI thread, which blocks the application for about 30 seconds if the folder contains some thousands files. (tried with e.g. user temp folder)
I have already tried the custom creation filter solution from Dimitar. It works already much faster. Blocking time is about 2 seconds, which is comparable with windows explorer, perhaps just for getting the files list.
I have still some questions:
- The scrolling is now somehow stuttering. Is there further optimization possibilities here? Would it bring something if I use other thread or async/await within creation filter?
- Still some problems with out of memory now. I would try to dispose the item icons if out of visibility. Is it possible?
Hello,
I am just checking about the progress of this issue. Let me know if you need my further assistance on this issue.
Thank you for using Infragistics Components.
I was pretty satisfied with your CreationFilter solution first. Then unlike your solution I haven't set item.Tag to null after initialization to allow e.g. update icon after rename, or get path of selected item. Now struggling with StackOverflowException caused on this statement:
item.SubItems[key].Value = value;
if you have an easy tipp other than to add IsInitialized property... no fun with our legacy sh....
I can't provide a sample call stack, because the task is currently postponed
Hi,
Thank you for the reply.
I have modified my sample, in order to demonstrate an approach that will hopefully prevent the StatckOverflowException. I don’t use the Tag property any longer. I was using it for convenience in my previous approach, but if you use the full path to the file as the item key you can get the File/Directory Info whenever needed. This way the objects in the application are reduced and hopefully the StackOverflow won’t happen. I also added the functionality to change the current folder by double clicking a folder item and going to the previous folder by pressing backspace and I also changed the adding of the items to use the AddRange method instead of the Add method.
Let me know if these suggestions fix your issue. If the exception still occurs, please provide me with some sample, which reproduces it (you can use mine as a starting point).
Please let me know if you have any additional questions.
Thank you for you example. Unfortunately I have currently no time to try it out, hopefully will in this month. But it is still interesting. I have a couple of questions.
What exactly prevents StackOverflow in you last example. Like I mentioned before, I proposed the cause was the subitem value setter:
item.SubItems[columnName].Value = columnValue;
Additionally I can already set some of subitem values and avoid some exceptions from file system at the point where the item will be added. Later in Creation filter I would make heavier things like get actual Icon and set Appearance, query the database for some other properties for the item. But not access the buggy file system anymore. Therefore i need some additional info object as a Tag. Is here something wrong with Tag what i should avoid?
I you example you manage the fileAppearanceDictionary. What speaks against disposable icons cache instead? What happens with Appearances if the control will be disposed. Will it free the icon instances? Is there not a memory leak?
Without seeing your application I can’t say for certain what will fix the StackOverflow exception and what won’t. I can’t reproduce it on my machine so I can’t know what exactly is causing it. Still I believe that the second approach I suggested is better than the previous one and since it is an improvement, I shared it with you.
I try to give you general suggestions on how to achieve your goal, but there are many approaches you can take. There is nothing inheritably wrong with using the Tag, but if memory usage is a concern you should try to avoid if possible storing data on it, especially if you do this for a large amount of items. The control will not dispose the appearances as they can be used in other controls and components. It is up to you to dispose them. I used a dictionary in order to keep track for which type of file I have already created an icon, so I don’t create unnecessary ones. You are free to use whatever caching mechanism you see fit.