RecordIndex on par with Microsoft's DLL debauchery

Hi,
After spending a number of hours trying to battle through code that is not working, I need to ask a few questions to sort out the behaviour I am seeing.
Usually when I am poking around at the DataController.Values[][] level, I am working against a non data aware column. But in this instance I am trying to set values of columns that are data aware. I am using a non data aware checkbox column. when the user checks that column, I need to set values in a number of other fields that are data aware. If I go the direct TDataset path, the changes made to the dataset are not reflected in the grid. Which is what I would expect. So again, I am back to pushing values in via the DataController.Values[][] array.
But if I push values in, once I move off the record, the changes are lost. Doing a DataController.Edit prior to adjusting the Values array does not help. that just puts the underlying dataset into edit mode. But if I use the DataController.SetEditValue method, the data will stick. But that seems to work directly against the DataController.EditingRecordIndex. That is fine for when the user clicks the checkbox since the EditingRecordIndex is the record I want to edit. But we also have options like "Select al in group" where we iterate over a number of grid rows/records in which case EditingRecordIndex is still pointing to the same record. Do I need to call the protected TcxCustomGridTableViewData.AssignEditingRecord as I move through the records?
So that leaves me stuck. I cannot find a way to manipulate the data via the GridView and force it to be applied to the table.
In addition, I want to know how permanent a recordIndex is. I was tracking some code, following the value of a TcxCustomGridRecord.recordIndex. It was the number I expected until (I think) I assigned a value via the Datacontroller.Values property. That same TcxCustomGridRecord instane is then passed to another method. But when I inspect the recordIndex in that method, it seems to have a completely arbitrary value. Sometimes -1, sometimes very large numbers. So my question is, does a RecordIndex change when the dataController.values change? In addition, I notice that when I manipulate this data in the grid, when there is a field grouping, those groups seems to collapse all by themselves. Is this "normal" grid behaviour? Or a side effect of assigning values to the Datacontroller.values property or whatever is causing the recordIndexes to change?
cheers
-randall

Hi Randall,
Let me first explain how the ExpressQuantumGrid (more precisely the ExpressDataController) manages its data. When the DataController loads data from a dataset, it creates a rectangular matrix (N rows x M columns) where records are ordered in the same manner as they were fetched from the dataset. We name these data rows "records", and you're referring to them when using the Values property of the DataController. When the data layout is changed (records are filtered, sorted or grouped), the DataController does not actually affect the original data matrix (the order of records remains the same). Instead, it uses logical "rows" which represent data in the current layout (taking sorting and grouping into account). "Rows" don't store any data, they just refer to corresponding "records".
We discussed this topic in report Q32378 ("Row/record index confusion"), and I recommend that you try the demo project, attached to that report. It illustrates how logical and physical indexes correspond to each other.
When you're working with the Table Controller (<GridView>.Controller), you should remember that it works only with logical data. The same is true for the ViewData object. So, their Records[]. Rows[], FocusedRow. FocusedRecord. FocusedRowIndex and FocusedRecordIndex properties actually provide the same values. You can easily see this in the source code … for example:

Delphi
cxGridCustomTableView.pas  

function TcxCustomGridTableController.GetFocusedRecord: TcxCustomGridRecord;  
begin  
  if (0 <= FocusedRecordIndex) and (FocusedRecordIndex < ViewData.RecordCount) then  
    Result := ViewData.Records[FocusedRecordIndex]  
  else  
    Result := nil;  
end;  

function TcxGridTableController.GetFocusedRow: TcxCustomGridRow;  
begin  
  Result := TcxCustomGridRow(FocusedRecord);  
end;  

I agree that this looks confusing, but this is actually the result of a rather complex inner structure of our Grid. When designing it, we thought that it may be necessary to deal with both logical rows and physical records at the GridView's level. We've finally decided to work only with logical data. However, it's necessary to keep both the Row~ and Record~ properties for backward compatibility.
Does this make sense?
Thanks,
Serge

OK, I think I have found why my code is not working. If you can confirm that the behaviour I am seeing is what you would expect:
We do a lot of work with unbound checkbox columns. Usually in these instances we maintain something like a TList of RecordIndex values so we know what is selected and what is not. But in this particular instance it is an underlying date field in the dataset bound to the grid. When the user clicks ont eh checkbox, we run this code:
procedure TfmDesignDB.cxEditRepositoryDataDefSelectCheckBoxPropertiesEditValueChanged(Sender: TObject);
var bChecked : boolean;
    iRecordIndex : integer;
    focusedRecord : TcxCustomGridRecord;
begin
  inherited;
  bChecked := TcxCheckBox(sender).checked;
  iRecordIndex := viewDataDef.DataController.FocusedRecordIndex;
  focusedRecord := viewDataDef.ViewData.GetRecordByRecordIndex(iRecordIndex);
  SelectedRowChange(focusedRecord, viewDataSelectCheckBox.Index, bChecked);
end;
And I can double check that when SelectedRowchange is called, focusedRecord.recordIndex has the value I expect…
SelectedRowchange looks like this:
procedure TfmDesignBase.SelectedRowChange(aGridRecord : TcxCustomGridRecord; iCheckBoxColIndex : integer; bIsSelected : boolean);
begin
  viewDataDef.DataController.Values[aGridRecord.RecordIndex, iCheckBoxColIndex] := bIsSelected;
  SelectedRowChanged(aGridRecord, bIsSelected);
end;
If I put a watch on aGridReocrd.recordIndex, the value changes when the Values array is assigned?!?! This may be behaviour you are expecting, but IMHO that is nuts. So the code is SelectedRowChanged, which then looks a aGridRecord.RecordIndex is now completely invalid.
I can address this, by passing around a aRecordIndex rather then aGridRecord and then using GetRecordByRecordIndex if I need the CustomgridRecord object again. But I need to know - why in the world, would the record index change just because I assigned a value to another column within the datacontroller.values array? I could understand that, if the column that I am changing happens to be the column we are currently sorted on. but it isn't.
I have to agree with what Toby Groves in Q32378 had to say… that I spend a LOT of time doing trial/error programming when it comes to the grid, and I've been working with it for about 2 years. The DevExpress components are supposed to simplify my life and speed my development. DevExpress should serious look at how to simplify things. For example, to create a "calcualted field" such as this checkbox column, should not be so difficult! It is frustrating to program and not be able to predict the behaviour of your code. And I pitty the poor soles that didn't purchase the source. They would surely be pulling their hair out.
my 2 cents
-rs

Hi,
Instead of using a data controller's Values property, use the SetEditValue method as shown in KB article: A343, How to set a value of another Grid column during editing of a cell. Please let us know your results.
Thanks,
Alex

OK, I will try that method. I had actually attempted to use SetEditValue previosuly, but I found that it caused an AV. This is most likely because I had set a value directly via the datacontroller.Values array previously. which seems to reinforce my theory that it is trashing the cache (the datacontroller.values array items) and recreating them, making my passed TcxGridReocrd object invalid.
Can you please confirm if my theory is correct. And if so, when exactly is the cache refreshed? Is it refreshed after every call to dataController.values[][] := xxxx ? Can it be postposed if, for example, I used dataController.begin/endUpdate?
cheers
randall

Hello Randall,
Please accept our apologies for the delay in answering. We need some additional time to research the problem. We'll contact you ASAP.
Thank you for your patience.
Thanks,
Stan.