When I create a new dataset from code or retrieve it via data adapter from the database, changing the row contents results to changed rowstate. That's the default behaviour and everything works correctly:
DataSet ds = new DataSet();
DataTable table = new DataTable("Cities");
table.Columns.Add("CityName", typeof(string));
table.Columns.Add("CountryName", typeof(string));
ds.Tables.Add(table);
table.Rows.Add("New York", "USA"); // state is Added for row 0
table.Rows.Add("London", "UK"); // state is Added for row 1
table.AcceptChanges(); // state is Unchanged for both rows
table.Rows[0][1] = "Seattle"; // state is Modified for row 0
When I retrieve a dataset from the database, then send it through wcf (yes I know it's a bad practice but that's a different story, I'm using the standard behaviour) and receive it on the proxy, its datarows are still "state-aware". The data rows still react to their value modifications.
Edit: After I debugged the issue further, I've found that the dataset is deserialized correctly and reflects the changes at the wcf client (rowstate corresponds to the modification of the cell value). The changes reflecting capability seems to be lost after each of the DataTable is bound (WPF hosted Windows Forms binding) to the FarPoint Spread Sheet object:
sheet = new SheetView("Sample");
DataTable table = obtainedDataSet.Tables[0]; // RowState is correct
sheet.DataSource = table; // from now on, RowState is "corrupt"
So from the point of binding the tables of the dataset into the FarPoint Spread Sheet object the rows are "state-ignorant". I may change their contents or call SetModified explicitly, but neither action changes its rowstate to modified:
obtainedDataSet.Tables[0].Rows[0][1] = "Seattle"; // state is Unchanged obtainedDataSet.Tabels[0].SetModified(); // state is Unchanged
Now is there any possibility of convincing the dataset to be wise again and start reflecting its changes or I need to consider a way different approach? Has anyone got any idea what might be wrong (binding itself or the FarPoint component, a wrong pattern)?
Well it seems that the problem was in the FarPoint Spread control. Version 5.0 broke the functionality and the guys at GrapeCity got the bug fixed in version 5.0.3518 which works fine now.