Hi,

Thank you for the reply.

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.

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?

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.

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.

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