jcmercure said:

The EndUpdate is executed in a method that is Invoked in the finally of a try/catch/finally within a data retrieval method that is executed in a thread.

This sounds like it might be the problem right here. Is your tree bound to a data source? If so, you cannot modify or access the data source on another thread. If you have a data retrieval method that is retrieving data on another thread and updating the data source that the tree is bound to, it's certain to cause problems just like the one you are having because things will get out of synch.

I took a look at the property where the exception is occurring (IsLastViewableSibling) and nothing has been changed in this code since 2005, so it seems unlikely that there's a bug here and no one noticed it until now.

Mike -

Thanks for the reply.  No the tree is not bound to a data source.  We create the nodes ourselves and add them to the tree.

The data retrieval is indeed done in a background thread which fills the tree using Invoke calls.  Am I correct in thinking that as long as we only touch the tree via Invoked calls there should not be a problem.  I have checked our code and I believe that there is no place that we touch the tree other than through an Invoke call.

I believe this likely a cross thread issue but I have not been able to reproduce it in the development environment to prove this.

Well, if the tree is not bound and you are certain that nothing in your code is touching the tree or it's data without properly invoking, then I'm not sure what is causing the exception.

This certainly feels like a threading issue, but I can't see your code, so I can't say if there is a hole somewhere that is updating the tree data on another thread. Are there other threads at work beside the data retrieval thread? Does some of your tree cells contain objects that might be referenced by the other thread?

Of course, it is always possible that this is a bug in the tree, but without a sample to reproduce the exception, there's no way to track it down.

Phalbert said:

I'm updating the control on a background thread using invoke and in most case it works, but occasionally it just crashes.

What exactly are you doing on the background thread? If your background thread is modifying the DataSource of any control (grid, tree, or any other control that is bound to it), then there is absolutely no way that your code can be safe.

Using an Invoke is not enough, because you are not in control of the communication between the bound control and the data source. There will be all sorts of things happening between the data source, the BindingManager, and the bound control that you cannot invoke because they happen automatically.

Hello

I'm getting this exact same random problem. Can update 20 time no worries, and then for no reason it crashes and throws an application exception.

I'm updating the control on a background thread using invoke and in most case it works, but occasionally it just crashes.

I replaced the tree with a grid and there's no crashing problem, so it's only the Tree that is causing the problem. I can't use the grid because it does not give me the layout i need...

I notice the problem is an "Object reference not set to an instance of an object." exception and not a 'Cross thread" exception, so I was wondering if further examination was required around what could create a NULL reference in your code base given the call stack.

My stacktrace is below. Any help greatly appreciated.

STACK TRACE

Object reference not set to an instance of an object.

Source Assembly: Infragistics2.Win.UltraWinTree.v10.3

Method: get_IsLastViewableSibling

Stack Trace:

at Infragistics.Win.UltraWinTree.UltraTreeNode.get_IsLastViewableSibling()

at Infragistics.Win.UltraWinTree.NodeClientAreaUIElement.ShouldDrawVerticalConnectorToBottom(TreeNodeUIElement nodeUI)

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)

at System.Windows.Forms.Control.WmPaint(Message& m)

at System.Windows.Forms.Control.WndProc(Message& m)

at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)

at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)

at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Hi,

jcmercure said:

I know you stated earlier that nothing changed in the particular code where the problem was occurring, but what about the code that called it. 

That's almost certainly the case, of course. Obviously something here has changed. But without being able to duplicate the issue, there's very little we can do to determine what changed may have caused it. And... if this is a threading issue, as I suspect, then it was probably sheer luck that it used to work in the old version.

Of course, there is always the possibility that I could be wrong and that this is not thread-related. But everything you are describing here has all the hallmarks of a threading issue.

Anyway, I'm afraid I cannot really isolate the changes from 8.2 to 9.2, as there are quite a large number of changes, so as I said, there's really not way to determine which change may have introduced this issue unless we can duplicate it.

Since you have so far been resistant to sending us a sample, I am assuming that it's probably pretty tough for you to do so. Your project is probably large and complex and includes references to data sources that we obviously don't have. But if you can't reduce the project down to something really small, then we could try to take a look at a larger project, assuming of course, that we can actually run it. So maybe you could try making a copy of your project and pointing it to some dummy data source, like an UltraDataSource or a DataTable you create in code with some fake data in it, just to repro the problem in a sample we can run.

I understand that this looks like a threading problem and I will continue to look through our code; although I have been through it twice now.

Wednesday last week I rolled back the NetAdvantage controls from version 9.2 to 8.2 because the upgrade appeared to be tied to some other problems we were having with your grid.  As it turns out the grid is not causing the other problem.

With the controls rolled back to 8.2, I tested the tree problem described above and found that I had been unable to duplicate the problem.  I decided to put this in production and our users who had been having the tree problem every day have not seen the problem since I rolled back the controls.  These errors had been being caught and reported in our event log and I have not seen an entry for this problem since the controls were rolled back.

I know you stated earlier that nothing changed in the particular code where the problem was occurring, but what about the code that called it.  Something has obviously changed in your code between 8.2 and 9.2 that is causing our users to experience the problem.  I found that I could reproduce the problem by moving the mouse over the tree while the tree was refreshing.  Was there a code change dealing with the mouse events in your code between versions 8.2 and 9.2.

We actually need to be at 9.2 because there is a 9.2 for a combo box bug that we reported earlier this year, but the tree problem we are experiencing is a bigger concern right now and so for the moment we will stick with the 8.2 roll back.

Hi,

Everything you are describing here is just getting more and more consistent with a threading problem.

To answer your question - yes, move the mouse over the tree can certainly cause element in the tree to get invalidated and those elements might attempt to access properties of the node which may be out of synch if the nodes are being modified from another thread.

My advice to you would be to examine your data retrieval code very thoroughly and make sure that nothing it is doing could possibly have any effect on the tree control and is not being invoked to the UI thread.