Hi Mike,

I had a very similar exception seen today. The only difference being that a summary value was being calculated as shown in the RefSummaryValueCollection in the stack trace. I have to admit that I have seen calculator bugs when using filtering since version 7.2 and have never updated the binding list on the grids except from the GUI thread. Their are five bands in the grid and there is a summary for band 2 that has a formula that references a value in the parent row and the sum of a column in the band 2 rows. There is also a summary for band 0 that is just a simple sum of each column.

I add, remove, or update the binding list periodically by doing an Invoke on the GUI thread and have seen calculator bugs (rarely however). I have removed the calculator as much as possible having even resorted to setting Row.Hidden to true instead of using a filter in previous projects but not this one. I am using version 8.2.20082.2204. The CalcFrequency is set to synchronous. I believe part of the problem is the fact that setting a filter is not a synchronous operation in the Grid so sometimes I have resorted to using EnsureSortedAndFiltered which is synchronous. This exception happened to one of our users so I cannot be exactly sure what they were doing when the exception occurred although as you mentioned above it look like a simple cell activation. Any help or suggestions you can give me would be appreciated. I am wondering at this point if I should resort to always using manual calculations to reduce the chance of an exception like this occuring again. However, I would prefer the bug to be simply fixed as opposed to have to jump through hoops to avoid it.

Here is the call stack:

I have finally had time to look at these bugs.  I will post my preliminary findings now.  I want to say the inavailability of .pdb files was a major issue preventing me from making any progress in these issues.  I believe this has been a bug in the ultracalc formula calculator since at least 7.1 and it looks like the last changes to the calculator code was back in 2004 from the source so it probably still exists today.  My preliminary findings lead to the understanding that the issue surrounds the calculation of formulas where the parent row is filtered out. 

My grid is bound to a hierarchical binding list.  There are filters on each band of the grid.  The calcmanager is set to Synchronous.  My FormulaRowIndexSource is set to Visible since I do not want to include filtered out rows in any calculated summation. 

What happens is that if I add a business object to the child binding list of a parent business object whose Row has been filtered out then I may get this exception: "Invalid scope in the reference: consolidatedbrokers(-1)."  This happens because the AbsoluteName of a CellReference used to calculate a summation that includes the newly added row is: //grid/legalentity(-1)/consolidatedbrokers(-1)/cashbalance.  That would be a reference to a cell for the formula "sum( [../brokers/cashbalance] )" in the parent row which is currently filtered out. legalentity being the name of the first band, consolidatedbrokers the second, and brokers the third.  There is also a formula on the first band of "sum( [../consolidatedbrokers/cashbalance] )" and there is a summary value for the first band which is "sum( [cashbalance] )". 

The source code showing what causes the bug is all from 8.2.20082.2204. 

Infragistics.Win.UltraWinGrid.RowReference.ElementName property will return the band name with row index -1 if the row is not visible and the row has never been visible which can happen if the parent row is filtered out.  lastValidIndex will be -1 and GetRowCalcIndex returns -1 because the row is not visible (filtered out).  This in itself is not a bug but just showing how the AbsoluteName path is formed when a parent row is filtered out.

public override string ElementName
{
    get
    {
        int rowCalcIndex = RefUtils.GetRowCalcIndex(base.Row);
        if ((rowCalcIndex < 0) && (base.lastValidIndex >= 0))
            rowCalcIndex = base.lastValidIndex;
        base.lastValidIndex = rowCalcIndex;
        string calcReferenceName = base.Row.Band.CalcReferenceName;
        StringBuilder builder = new StringBuilder(calcReferenceName.Length + 8);
        builder.Append(calcReferenceName).Append('(').Append(rowCalcIndex).Append(')');
        return builder.ToString();
    }
}

The AbsoluteName property of the CellReference for consolidatebroker band column "cashbalance" is AbsoluteName of "//grid/legalentity(-1)/consolidatedbrokers(-1)/cashbalance".  That column has formula "sum( [../brokers/cashbalance] )".  Now when a child broker object is added to the binding list the grid performs a synchronous calculation for the newly added row for that business object and the parent rows.  To evaluate the formula for cashbalance for the parent row the following method is used from class Infragistics.Win.CalcEngine.UltraCalcFunctionSum:

Hi Mike,

Thanks for opening the case to resolve this if it was you.  The developer was unable to reproduce it so I modified the Samples\WinCalcManager\CS\WinGrid Summaries CS project. 

Frankly I am astonished that this bug has been in infragistics for so long since its a very basic operation that creates the exception.  The bug can be summarized as follows:  If a row is added to the grid for band 0, and a child band of that new row has summary values, and the filter on band 0 would cause the new row to be filtered out, then the exception occurs. 

Here's a screenshot of the application.