Infralution Support Forum Index Infralution Support
Support groups for Infralution products
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Collection was modified; enumeration operation may not execu
Goto page 1, 2  Next
 
Post new topic   Reply to topic    Infralution Support Forum Index -> Virtual Tree Support
View previous topic :: View next topic  
Author Message
keesp
Guest





PostPosted: Wed Sep 07, 2005 12:21 pm    Post subject: Collection was modified; enumeration operation may not execu Reply with quote

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

PostPosted: Wed Sep 07, 2005 10:54 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Infralution



Joined: 28 Feb 2005
Posts: 5027

PostPosted: Fri Sep 09, 2005 2:41 am    Post subject: Reply with quote

This issue should be fixed by the latest release (2.0.3) which is now available for download.
_________________
Infralution Support
Back to top
View user's profile Send private message Visit poster's website
RGabo



Joined: 21 Sep 2005
Posts: 11

PostPosted: Wed Sep 21, 2005 7:36 pm    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger MSN Messenger
Infralution



Joined: 28 Feb 2005
Posts: 5027

PostPosted: Wed Sep 21, 2005 9:58 pm    Post subject: Reply with quote

Are you using the latest version (2.0.4) ?
_________________
Infralution Support
Back to top
View user's profile Send private message Visit poster's website
Guest






PostPosted: Thu Sep 22, 2005 12:22 am    Post subject: Reply with quote

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

PostPosted: Thu Sep 22, 2005 12:24 am    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger MSN Messenger
Infralution



Joined: 28 Feb 2005
Posts: 5027

PostPosted: Fri Sep 23, 2005 1:53 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
RGabo



Joined: 21 Sep 2005
Posts: 11

PostPosted: Fri Sep 23, 2005 1:30 pm    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger MSN Messenger
Infralution



Joined: 28 Feb 2005
Posts: 5027

PostPosted: Sun Sep 25, 2005 7:24 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
RGabo



Joined: 21 Sep 2005
Posts: 11

PostPosted: Tue Sep 27, 2005 5:20 pm    Post subject: Reply with quote

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
View user's profile Send private message Yahoo Messenger MSN Messenger
keesp
Guest





PostPosted: Wed Oct 05, 2005 8:27 am    Post subject: expanding revisited Reply with quote

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

PostPosted: Wed Oct 05, 2005 8:46 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Infralution



Joined: 28 Feb 2005
Posts: 5027

PostPosted: Thu Oct 06, 2005 12:34 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
keesp
Guest





PostPosted: Mon Oct 24, 2005 9:26 am    Post subject: repainting and updating rows Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic    Infralution Support Forum Index -> Virtual Tree Support All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group