Say I want to default the value of cells B and C based on the data input into cell A, how do I do this.
My thought was to save e.PreviousActiveCell and e.NewActiveCell in the ActiveCellChanging event and then set the value in the ActiveCellChanged event, or alternatively set the values in the EnteringCell event.
However this doesn't work because there seems to be strange delay before ActiveCell.Row.Data gets updated. If A is a TextColumn then Row.Data.A appears to still be null when I enter cell B, and not have a value until I enter C. And if A is a TemplateColumn, which in my case it is, Row.Data.A does not seem to get filled until I actually leave (commit) the row.
Hi,
So when a user enters a value when A is edit mode, you want to change B and C?
Are B and C bound fields?
You could set B and C in the setter of A.
You could use the CellExitEditMode event of the xamGrid and check if the Column is A, and then update the underlying row data.
I'm not sure that ActiveCell really makes the most sense.
-SteveZ
Is there any way to force the interface to immediately update the underlying bound Row.Data rather than having to hard code it for each cell when needed? Why is there a delay in the underlying Row.Data being updating, where is the value being stored in the meantime, should the binding be directly to the underlying table?
Part of the reason for asking this is because I am also encountering a much more serious bug that seems to be also caused by the same issue. In this case I have a user control bound in the template column. When a new row is Added and a value is put into this cell, instead of updating that row, it seems to update the AddRow underlying data only. Once the row is commited, a new row is created, but with that cell blank, whereas the value of the cell remains in the AddRow.
correction: 'shouldn't the binding be (already) directly to the underlying table?', it does change the meaning of the sentence.
Also, I've created a new thread for the second more serious problem.
When ActiveCellChanged is raised we have already updated the underlying data value if you were in edit mode, there should be no delay.
However, at that point, the ActiveCell could be on a different row. So the row.data you're looking at could be different.
If you are using ActiveCellChanging, we don't exit edit mode until after this event, in case it gets cancelled. Note: we are using bindings still, however the UpdateSourceTrigger is set to explicit, which means the new value is in the editor still until we tell it to update it's Source.
Thus, if you use CellExitedEditMode, you'll have the correct data.