Hello Ken,

Could you please provide a reproduction sample for this error? We will use the sample to look into the issue and get you a solution as soon as possible.

In the meantime, you should be able to reference either the assemblies for 2041 or the Release Version (Build 1000).

Hi Ken,

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?

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.

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?

-Ken

Hi Ken,

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();
}

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?

Hi Mike,

I can tell you that we have some code that pulls a list of user objects. We loop through the list and programmatically create nodes and add them to the tree. There might be 4000+ nodes being added.

tree.Nodes.Clear();

foreach (UserNode userNode in BuildUserNodes(users))
      tree.Nodes.Add(userNode);
Refresh();

basically the code above causes the scrollbar rendering to fail (red X)
and it throws the same error as above. When it is trying to PositionChildElements() it chokes. This doesn't happen in the 2041 service release.

at Infragistics.Win.UltraWinTree.NodeClientAreaUIElement.PositionChildElements()
   at Infragistics.Win.UIElement.VerifyChildElements(ControlUIElementBase controlElement, Boolean recursive)

I will try to create a simple example in my spare time but for now this might get you started.

thanks for getting back to me.
-Ken