View previous topic :: View next topic |
Author |
Message |
keesp Guest
|
Posted: Wed Sep 07, 2005 12:21 pm Post subject: Collection was modified; enumeration operation may not execu |
|
|
Hi,
I am facing the following error under very specific circumstances, and I was wondering if anyone could help me with this issue.
What happens. I start building a tree by dragging treenodes in virtual tree.
When I have the following tree structure:
(+)A-|
|-(-)B
|-Z
I open the treeNode B (the entire structure with C and D was dragged in, but initially B was collapsed):
(+)A-|
|-(+)B-|
| |-C
| |-D
|-Z
Now I drag in a new node E by dropping it on Z.
This drop causes an event that eventually calls the following method:
protected void UpdateFromRow( TreeNode node, bool reloadChildren, bool recursive )
{
this.SuspendLayout();
Row row = this.FindRow( node );
try
{
row.UpdateChildren( reloadChildren, recursive );
}
catch( Exception ex )
{
Console.WriteLine( ex.Message + "\n" + ex.StackTrace );
}
this.ResumeLayout();
this.Refresh(); //Force repainting of the tree
}
both reloadChildren and recursive is true (and the latter causes the problems).
Now I get the previously mentioned exception:
Collection was modified; enumeration operation may not execute.
at System.Collections.SortedListEnumerator.MoveNext()
at Infralution.Controls.VirtualTree.Row.UpdateChildrenNoReindex(Boolean reloadChildren, Boolean recursive)
at Infralution.Controls.VirtualTree.Row.UpdateChildrenNoReindex(Boolean reloadChildren, Boolean recursive)
at Infralution.Controls.VirtualTree.Row.UpdateChildren(Boolean reloadChildren, Boolean recursive)
at EcoChemie.NovaCV.Controls.VirtualTree.CommandVirtualTree.UpdateFromRow(ITreeViewNode node, Boolean reloadChildren, Boolean recursive) in c:\products\nova\novacv\source\ecochemie.novacv.controls\virtualtree\commandvirtualtree.cs:line 771
From then on, virtual tree is no longer working.
It is very hard for me to make a small project to isolate the bug, so I hope that maybe I can be helped by giving a detailed account of the circumstances. I have tried various things, including adding UpdateRowData in the previously mentioned method, but it does not seem to help. Setting recursive to false ends the problem, but introduces new ones when dragging subtrees in the tree.
I DO have a theory. Currently I do not do anything when I expand tree node B. This action does make the entire tree larger and I get the feeling that this causes an internal mismatch between row and data. However, I though that updateRowData would repair the mismatch, but this does nnot seem to be the case.
I hope you may have a solution for me.
thanks,
Kees |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Wed Sep 07, 2005 10:54 pm Post subject: |
|
|
The exception is probably occurring because GetChildrenForRow (or some other method called from UpdateChildren) is in turn causing another update. This means that the internal collection used by Virtual Tree is modified while we are iterating over it. We will change this in the next minor release to make the iteration more robust and cope with this type of rentrancy (either by copying the internal collection or by iterating using index rather than an enumerator). _________________ Infralution Support |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Fri Sep 09, 2005 2:41 am Post subject: |
|
|
This issue should be fixed by the latest release (2.0.3) which is now available for download. _________________ Infralution Support |
|
Back to top |
|
|
RGabo
Joined: 21 Sep 2005 Posts: 11
|
Posted: Wed Sep 21, 2005 7:36 pm Post subject: |
|
|
Unfortunately this happens also when I call UpdateRowData. I can trigger it more often if I keep scrolling the control. I only change properties of the objects that have been passed in as the DataSource. I bind to a single object that has a Children property that returns the elements that I want to see.
It also tells me that 'failed to register DragDrop'. Any clues why this could happen?
Gabor |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Wed Sep 21, 2005 9:58 pm Post subject: |
|
|
Are you using the latest version (2.0.4) ? _________________ Infralution Support |
|
Back to top |
|
|
Guest
|
Posted: Thu Sep 22, 2005 12:22 am Post subject: |
|
|
Infralution wrote: | Are you using the latest version (2.0.4) ? |
Yes, I am. I will try to reproduce now again.
Gabor |
|
Back to top |
|
|
RGabo
Joined: 21 Sep 2005 Posts: 11
|
Posted: Thu Sep 22, 2005 12:24 am Post subject: |
|
|
That was me, not logged in.
Unfortunately I can still reproduce the error. Heavy scrolling and calling UpdateRowData will trigger the exception.
RGabo |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Fri Sep 23, 2005 1:53 am Post subject: |
|
|
Are you sure the stack trace is the same as in the earlier post? If you can put together a sample that exhibits the problem and email it to us (support@infralution.com) that would really help. _________________ Infralution Support |
|
Back to top |
|
|
RGabo
Joined: 21 Sep 2005 Posts: 11
|
Posted: Fri Sep 23, 2005 1:30 pm Post subject: |
|
|
Infralution wrote: | Are you sure the stack trace is the same as in the earlier post? If you can put together a sample that exhibits the problem and email it to us (support@infralution.com) that would really help. |
The stack trace is different, of course. I will try to make a sample but also past the strack trace here.. |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Sun Sep 25, 2005 7:24 am Post subject: |
|
|
Its really only the bottom end of the stack trace (ie in the Infralution code) that is important as far as we are concerned. This type of exception can occur in a few different place and perhaps we have not covered all possible places. _________________ Infralution Support |
|
Back to top |
|
|
RGabo
Joined: 21 Sep 2005 Posts: 11
|
Posted: Tue Sep 27, 2005 5:20 pm Post subject: |
|
|
Infralution wrote: | Its really only the bottom end of the stack trace (ie in the Infralution code) that is important as far as we are concerned. This type of exception can occur in a few different place and perhaps we have not covered all possible places. |
The problem was my fault as I was calling an instance method of the control from a different thread. I didn't realize the callback came from a different thread. As Control.InvokeRequired was true, I am now asynchronously calling my Update method with the thread that created the control with Control.Invoke.
Thanks! |
|
Back to top |
|
|
keesp Guest
|
Posted: Wed Oct 05, 2005 8:27 am Post subject: expanding revisited |
|
|
The problem I sketched earlier does not seem to occur any more, at least the exception no longer is thrown. However there is still a bit unusual behaviour. When I add a reasonably large tree and expand some of the nodes, the first time will always result in the bottom end of the tree disappearing out of sight. If I collapse the node again and expand it again it suddenly works okay, and from then on there is no problem.
So it looks as if the repainting isn't completed entirely the first time.
If it is a help, I could add some screen shots of the actions to sho what I maen, but it is hard to provide any additional information, as no exceptions are thrown, and none of overridden methods are called.
Thanks
Kees |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Wed Oct 05, 2005 8:46 am Post subject: |
|
|
Screen shots would certainly help. A sample application project would be even better. My guess is that this as was mentioned above a result of calling UpdateRows from within code that was in turn ultimately called by UpdateRows. If you can avoid this sort of thing you may be able to eliminate the issue. _________________ Infralution Support |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Thu Oct 06, 2005 12:34 am Post subject: |
|
|
If you really need to call UpdateRows from code that is ultimately called from UpdateRows you could consider doing this asynchronously eg
Code: |
public delegate void UpdateRowsDelegate();
...
tree.BeginInvoke(new UpdateRowsDelegate(tree.UpdateRows));
|
This should avoid any issues with reentrant code. _________________ Infralution Support |
|
Back to top |
|
|
keesp Guest
|
Posted: Mon Oct 24, 2005 9:26 am Post subject: repainting and updating rows |
|
|
Hi,
The problem sketched previously, that part of a tree is not repainted, does not seem to occur if I listen to the RowExpand event and perform an updaterowdata from there.
However, I don't consider this to be a good solution, for every expand action will cause an updaterowdata and slow the update process down tremendously. I can improve this behaviour, but it still seems to me to be a workaround.
As far as I can tell, adding a large branch to an existing tree, especially at the bottom, can result in a partial repainting of the virtual tree, up to the amount of rows that were previously visible. Therefore adding a branch to this tree will make part of the resulting tree disappear.
As said earlier, collpasing and expanding the resulting tree will work perfectly, and calling updaterowdata with every rowexpand event will also work fine.
I have seen that a row expand action can cause a cascade of rowexpand events, which is correct behaviour, as every collapsed row that is expanded can itself show new rows that have to expanded as well (e.g. when also expanding children). My analysis so far is, that every row expand action, also those that cascades through the tree, should at completion (so when the cascade of events have finished) result in an updaterowdata.
Another possible cause could of course be that a certain overridden method might cause the problems, but so far I have found none of the most likely candidates (rowbinding methods and cellbinding methods) to cause any problems.
I am sorry that I'm currently not able to provide any source code (much to big...)
Kind regards,
Kees |
|
Back to top |
|
|
|