I have a User Control with a tree that has work flawless for two years. We just updated to the latest SR 2063 and when we start to scroll the control we get this explosion.
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.DrawHelper(Graphics graphics, Rectangle invalidRectangle, Boolean doubleBuffer, AlphaBlendMode alphaBlendMode, Boolean clipText, Boolean forceDrawAsFocused, Boolean preventAlphaBlendGraphics) at Infragistics.Win.UIElement.Draw(Graphics graphics, Rectangle invalidRectangle, Boolean doubleBuffer, AlphaBlendMode alphaBlendMode, Boolean forceDrawAsFocused, Boolean preventAlphaBlendGraphics) at Infragistics.Win.ControlUIElementBase.Draw(Graphics graphics, Rectangle invalidRectangle, Boolean doubleBuffer, AlphaBlendMode alphaBlendMode, Size elementSize, Boolean preventAlphaBlendGraphics) at Infragistics.Win.ControlUIElementBase.Draw(Graphics graphics, Rectangle invalidRectangle, Boolean doubleBuffer, AlphaBlendMode alphaBlendMode, Size elementSize) at Infragistics.Win.ControlUIElementBase.Draw(Graphics graphics, Rectangle invalidRectangle, Boolean doubleBuffer, AlphaBlendMode alphaBlendMode) at Infragistics.Win.UltraControlBase.OnPaint(PaintEventArgs pe) at Infragistics.Win.UltraWinTree.UltraTree.OnPaint(PaintEventArgs pe) at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
Hi Mike,
Yes, I was able to work around the issue using 2041. That was the basis of why I said 2063 has introduced a bug.
I haven't gotten a chance to load 2063 source code and find the actual problem code. I hope to get that in sometime this week.
-Ken
Hi Ken,
Were you able to work around this issue using the assemblies for build 2041? Please let us know if you have any further questions.
kvillines said:I didn't write that code so I don't know why Refresh() was getting called. That code is about 20 lines in a form that contains about 1400+ lines of code. The Refresh() shouldn't be causing a problem with your painting code....I would hope not anyway, or you do have a problem.
Refresh is not a problem - all it does it force the control to paint itself. The reason I mentioned it is that there is very rarely a reason to force a paint. The fact that your code is doing so may indicate that there is something else going on here.
If your code worked in a previous version and it is raising an exception, now, then that's clearly a serious problem and we want to get it resolved. My suggestion was only intended to help you make your code more efficient and if it happens to work around the Exception until we can get it fixed, all the better.
kvillines said:Like I said further up, ALL of our code worked fine until we applied the 2063 service release. It seems to me you guys can do a diff in the file where the stack trace is and see what changed between 2041 and 2063. AND see where the possible NullReference could be taking place.
Unfortunately, it's almost never that simple. Just because the exception occurs in that particular method doesn't mean that the change which caused the exception is in that same method.
But I took a look, just to be sure. There were not changes to that file between build 2041 and 2056.
kvillines said: I am not sure why you guys always want your customers to take their time to build you demos. Our company already pays for your top product and you guys can't support it when their are problems? A stack trace should lead you to where the problem is...period.
As I explained, this is not true in any but the most simple cases.
The reason we ask for samples demonstrating a problem is that it's the best way to make sure that the actual problem you are experiencing is fixed. We can try to recreate the exception you are getting, but this is often impossible, since there are literally an infinite variety of property settings, method calls, event handles, etc. that could be involved in causing the issue. If we get a sample from you that demonstrates the problem, we can track it down and fix it and be assured that the bug we fixed is the one you are actually experiencing.
Without a sample that duplicates the bug, we are only guessing - there's no way for us to be sure we fixed the issue.
kvillines said: The problem doesn't only happen with the code above. It also happen with normal binding and drawing. We bind during the load of the form. Later we show the tree on a click and start to scroll through and BAM! it crashes trying to draw the children. We change back to 2041 and No Crash The problem is with your code and haven't been able to create a simple example that causes the problem. That being the case, I can't take any more time on tracking down YOUR bugs because I have my own development to do. The bottom line is why would I recommend paying for the next yearly upgrade when your stuff isn't working for us?
The problem doesn't only happen with the code above. It also happen with normal binding and drawing. We bind during the load of the form. Later we show the tree on a click and start to scroll through and BAM! it crashes trying to draw the children. We change back to 2041 and No Crash
The problem is with your code and haven't been able to create a simple example that causes the problem. That being the case, I can't take any more time on tracking down YOUR bugs because I have my own development to do.
The bottom line is why would I recommend paying for the next yearly upgrade when your stuff isn't working for us?
I understand your frustration. We work hard to make sure our controls are backward compatible and that we don't introduce bugs like this. But no system is perfect, and other bugs must be fixed, and new features must be added and that process involves some risk of introducing new bugs. We do our best to keep those to a minimum, but sometimes they happen despite our best efforts.
Since you have have narrowed it down to 2 builds here, I took a look and I can see that here were 5 bugs fixed in the WinTree between build 2041 and 2056. So we can take a glance and see if anything that might be causing a NullReferenceException jumps out at us. But as I said above, without a sample, even if we spot a problem, it may not be the problem you are actually experiencing, and there is no way to know for sure.
I didn't write that code so I don't know why Refresh() was getting called. That code is about 20 lines in a form that contains about 1400+ lines of code. The Refresh() shouldn't be causing a problem with your painting code....I would hope not anyway, or you do have a problem.
Like I said further up, ALL of our code worked fine until we applied the 2063 service release. It seems to me you guys can do a diff in the file where the stack trace is and see what changed between 2041 and 2063. AND see where the possible NullReference could be taking place.
I am not sure why you guys always want your customers to take their time to build you demos. Our company already pays for your top product and you guys can't support it when their are problems? A stack trace should lead you to where the problem is...period.
I don't see why any of the code you have here should cause an exception, but this code could be made much more efficient like so:
tree.BeginUpdate(); try { tree.Nodes.Clear(); foreach (UserNode userNode in BuildUserNodes(users)) tree.Nodes.Add(userNode); } finally { tree.EndUpdate(); }
tree.BeginUpdate();
try
{
tree.Nodes.Clear(); foreach (UserNode userNode in BuildUserNodes(users)) tree.Nodes.Add(userNode);
}
finally
tree.EndUpdate();
That might help with the exception, too, since the tree will not have to paint (or verify the child elements) until all the nodes are added.
Also, why are you calling Refresh? I assume this is the Refresh method of the form?