check your Series collection and make sure there are only GanttSeries in there, as that might cause a problem.

what's happening is, a hit test occurs (for tooltips, most likely), finds a primitive, and sees that its Layer property is a GanttLayer.  it then tries to index into an internal GanttSeries collection using the primitive.Row property value.  if there are any tooltip-capable primitives in your SceneGraph with a Row higher than the index of the last GanttSeries, the exception will be thrown.

so, my best guess is an issue with the Series collection containing non-Gantt series.  my second best guess is a FillSceneGraph event handler adding primitives with an invalid row number.

if none of those work, and if you're unable to provide a sample project, try downloading the controls' source code if you own a copy; this can be a valuable debugging resource under circumstances like this.  for example, if you debug into our source code where the exception is thrown, you can find out more information about the primitive that's causing a problem in hit testing.

Hi David,

It’s taken me a while to get back to this – but I have.  I downloaded the source code as suggested and am pretty sure that the problem lies within the UltraWinChart code.

I believe the problem is to do within the DefaultTool class in that it contains a class-level variable called “oldPrimitive” which holds a reference to the last primitive over which the mouse was moved.  The problem is that this reference is never set to null.  I will do my best to describe the process by which the error occurs:

1. The mouse is moved onto the UltraWinChart control and the OnMouseEnter sub is run.  The last line of this sub instructs the IInteraction tool for the UltraWinChart to start; i.e.  this.tool.Start().  The property code for the internal Tool property firsts tests if the backing field for the property (i.e.  this.tool) is null, and if it is it sets it to this.defaultTool.  At this stage the DefaultTool.oldPrimitive backing field is null.
2. The mouse is moved over an UltraWinChart primitive at which point the UltraWinChart.OnMouseMove sub is run which in turn calls the this.Tool.MouseMove sub which in turn calls its own ProcessMouseMove subroutine.  This latter sub performs a HitTest to determine if the mouse is over a primitive.  The last line of the ProcessMouseMove then transfers the reference to from the local hitPrimitive variable to the oldPrimitive class-level variable.  This is ultimately the cause of the problem under certain conditions.
3. The mouse is moved out of the UltraWinChart control and the OnMouseLeave sub is run.  The first line of this sub sets the internal Tool property to null.  However, the private defaultTool field still exists and its oldPrimitive still references an existing primitive.
4. My code then destroys all Series and Time Entries from the UltraWinChart and then creates a whole bunch of new ones relating to a newly selected Job.
5. The mouse is then moved back over the UltraWinChart control and the OnMouseEnter sub is run once again and its last line once more instructs the IInteraction tool for the UltraWinChart to start; i.e.  this.tool.Start().  As before, the property code for the internal Tool property firsts tests if the backing field for the property (i.e.  this.tool) is null, and because it is it sets it to this.defaultTool.  Now at this stage the DefaultTool.oldPrimitive field is still referencing a primitive that no longer exists.
6. The mouse is moved over a UltraWinChart primitive object at which point the UltraWinChart.OnMouseMove sub is invoked which in turn invokes the this.Tool.MouseMove sub which in turn calls its own ProcessMouseMove subroutine.  This latter sub performs a HitTest to determine if the mouse is over a primitive.  However, latter in this ProcessMouseMove the oldPrimitive variable is used as follows:

ChartDataEventArgs hitEvent = this.UltraChart.ChartCore.GetChartInfoFromPrimitive(oldPrimitive);

The problem here is that the oldPrimitive variable still contains a reference to a primitive that no longer exists.  And hence an exception is thrown within the GetChartInfoFromPrimitive method on the line GanttSeries currentSeries = series[prim.Row].  It is only later in the ProcessMouseMove sub that the oldPrimitive field is given a new value.

So the solution I came up with was to create some code that releases the reference to oldPrimitive from within the DefaultTool class.  This is what I did:

1. Within the IInteractionTool interface I added:
    /// <summary>
    /// Releases references to any primitives.
    /// </summary>
    void ReleasePrimitiveReferences();

2. Within the InteractionTool class I added:
    /// <summary>
    /// Releases references to any primitives.
    /// </summary>
    public virtual void ReleasePrimitiveReferences()
    {
    }

3. Within the DefaultTool class I added:
    /// <summary>
    /// Releases references to any primitives.
    /// </summary>
    public override void ReleasePrimitiveReferences()
    {
      oldPrimitive = null;
    }

4. Within the UltraWinChart controls Tool property set code I added a call to this new ReleasePrimitiveReferences sub as follows:

    internal IInteractionTool Tool
    {
      get
      {
        if (tool == null) tool = this.defaultTool;
        return tool;
      }
      set
      {
        if (this.tool != value)
        {
          if (this.tool != null)
            this.tool.Stop();

Through this code then whenever the UltraWinCharts tool property is set to null, and hence the defaultTool is used, then the reference to the oldPrimitive is released.

I’m sure you guys might have a another (possibly better) way of achieving the same result, but I believe that the oldPrimitive variable has to release its reference to any primitives once the mouse leaves the UltraWinChart control.

Cheers, Tony.

thanks for the detailed report.  we will keep this for review next time we need to make an adjustment to the mouse interaction code.

for now, your solution sounds good, but since i haven't been able to reproduce the ArgumentOutOfRangeException, i can't really justify the risk of side effects.

i did, however, add some bounds checking to prevent from indexing into the Series collection with an invalid value ... this fix will be included in an upcoming service release.  i can't tell if that will make your application work properly where the exception was thrown before, but i expect it will.