Forgot to include the call stack:

   at System.Collections.ArrayList.get_Item(Int32 index)
   at Infragistics.Win.UltraWinTree.UltraTreeNode.IsFirstVisibleNodeInIslandHelper(Int32 topNodeVisibleIndex)
   at Infragistics.Win.UltraWinTree.UltraTreeNode.DisplaysHeaderAreaHelper(Int32 topNodeVisibleIndex)
   at Infragistics.Win.UltraWinTree.UltraTreeNode.get_DisplaysHeaderArea()
   at Infragistics.Win.UltraWinTree.NodeClientAreaUIElement.PositionChildElements()
   at Infragistics.Win.UIElement.VerifyChildElements(ControlUIElementBase controlElement, Boolean recursive)
   at Infragistics.Win.UIElement.VerifyChildElements(Boolean recursive)
   at Infragistics.Win.UIElement.VerifyChildElements()
   at Infragistics.Win.UltraWinTree.UltraTreeUIElement.PositionChildElements()
   at Infragistics.Win.UIElement.VerifyChildElements(ControlUIElementBase controlElement, Boolean recursive)
   at Infragistics.Win.UIElement.VerifyChildElements(Boolean recursive)
   at Infragistics.Win.UIElement.VerifyChildElements()
   at Infragistics.Win.UltraWinTree.UltraTreeNode.BringIntoViewHelper(Boolean includeChildNodes, Boolean includeHorizontal, Boolean includeVertical, Boolean leftOnly)
   at Infragistics.Win.UltraWinTree.UltraTreeNode.BringIntoViewHelper(Boolean includeChildNodes, Boolean includeHorizontal)
   at Infragistics.Win.UltraWinTree.UltraTree.SetActiveNode(UltraTreeNode node, Boolean bringIntoView, Boolean adjustHorizontalPosition)
   at Infragistics.Win.UltraWinTree.UltraTree.SetActiveNode(UltraTreeNode node, Boolean bringIntoView)
   at Infragistics.Win.UltraWinTree.UltraTree.SetActiveNode(UltraTreeNode node)
   at Infragistics.Win.UltraWinTree.UltraTree.set_ActiveNode(UltraTreeNode value)
     

I was not able to reproduce this problem with the latest build; I tried (1) activating a node that is out of the viewable area on a buttom click and (2) activating a child of a collapsed node, and I didn't get an exception. Since more than one person got this to happen it is obviously not terribly difficult to reproduce, but either I am missing a step or the bug has already been addressed. If you can post a small sample that demonstrates the problem, or provide any details that might help to reproduce, we can take a look.

Thank you for attempting to track this down

I was hoping a diff of 2009.1000 and 2009.2012 would show up changes in wintree that could make these things happen

In case this helps
It only occurs in our program if you try to

ultraTree1->ActiveNode=keyNode;

a node that Exists and is Visible
if you collapse the tree the crash does not occur

I will try to write a example program but our real world program makes heavy use of infragistics and i bet I wont be able to make it occur in a small proglet

I will try on monday 

Again many thanks

Ok spent alot of time creating a proglet that pretends to do what
our real world application does and there is NO crash :¬(

But.... I did some random code slashing to see if i could get the problem to dissapear
and I found that twhen i moved the
ultraTree1->EndUpdate() before the ultraTree1->Active=keyNiode
the crash went away

I belive the crash is to do with our usage of
Node->Override->NodeAppearance and this setactive before the endupdate
but its a guess

--------------------FROM-------------------

// Begin Update
ultraTree1->BeginUpdate();
ultraTree1->Nodes->Clear();
ultraTree1->ImageList=imageList1;
for(i=0;i<40;i++){
  ultraTree1->Appearances->Add();
  ultraTree1->Appearances[i]->Image=i;
}

// DO LOTS OF NODE ADDS HERE

//
ultraTree1->ActiveNode=keyNode;
ultraTree1->ActiveNode->BringIntoView();

// End Update
ultraTree1->EndUpdate();

------------------- TO --------------------------

// Begin Update
ultraTree1->BeginUpdate();
ultraTree1->Nodes->Clear();
ultraTree1->ImageList=imageList1;
for(i=0;i<40;i++){
  ultraTree1->Appearances->Add();
  ultraTree1->Appearances[i]->Image=i;
}

// DO LOTS OF NODE ADDS HERE

// End Update
ultraTree1->EndUpdate();

//
ultraTree1->ActiveNode=keyNode;
ultraTree1->ActiveNode->BringIntoView();

-----------------------------------------------------

Yes, the cause is setting the ActiveNode while painting is suspended. That is of course a bug which will be addressed in a future release. The easiest solution for you is to move the ActiveNode assignment outside the BeginUpdate/EndUpdate block, since you gain nothing by having it in there anyway.

we are getting the same error too, how can i download build 2029.  Thanks.

This issue seems resolved (for us, anyway) as of build 2029.  Thanks.

I have the same problem without any BeginUpdate(). However EndUpdate() works as a workaround for me, too. I guess the VisibleNodesManager stuff called from EndUpdate() does what has to be done..

bmcloughlin and dpalau:

I've passed the information on this thread to Developer Support, so that a support case will be logged for each of you.  That way, you'll be notified when a service release containing the changes that Brian mentions is published.  The workaround Brian mentioned should get you up-and-running again in the meantime.

Thank you for verifying my findings :¬)