This is a small logic question. My datagrid has date time values in chronological order.
If the user enters an out-of-order date time, the program should highlight the row which is out-of-order.
For eg: This is the initial order.
10/5/2010 11:59:59
10/6/2010 00:00:00
10/6/2010 11:59:59
Suppose the user enters
10/5/2010 11:59:59
***10/7/2010 00:00:00***
10/6/2010 11:59:59
10/7/2010 00:00:00
here 10/7/2010 00:00:00 is the out of order and the program behaves correctly.
Suppose the user enters
10/5/2010 11:59:59
10/6/2010 00:00:00
***10/5/2010 11:59:59***
10/7/2010 00:00:00
Here 10/5/2010 11:59:59 is the out or order row. But the program highlights 10/6/2010 00:00:00.
Here’s my code to check the above:
for (int nRow = 1; nRow < pSeries.Count; ++nRow)
{
// validation1
if (!check_range(nRow, i, pSeries[nRow].tim))
{
row = nRow;
err = (short)err_typ.e_out_range;
goto err_exit;
}
}
public bool check_range(int np, int nCol, DateTime dt)
{
DataArray pdata = GetDataArray(nCol);
bool valid = (np <= 0 || pdata[np - 1].Datetim <= dt) &&
(np >= (pdata.Count - 1) || dt <= pdata[np + 1].Datetim );
return valid;
}
DataArray is a user defined array of datetime values. pSeries,pData are of type DataArray.
So when I say pdata[np - 1].DateTime it refers to the datetime cell.
Your code says that for a sequence (A, C, B, D), C is considered out of order because C does not fall between A and B.
In the case of the sequence (5.0, 6.0, 5.1, 7.0), your current code will find that 6.0 does not fit between 5.0 and 5.1, and therefore 6.0 is out of place. Your problem description, though, indicates that you have another criterion for deciding whether a row is out of place which is not represented in your code.
I’m going to guess that the additional rule is something like this: if N+1 fits between N-1 and N, then N+1 is the row that is out of place, not row N.
For the sequence (5.0, 6.0, 5.1, 7.0) if we first test this new rule, then it will flag 5.1 as the out of place row. If the new rule returns false, then we continue on with your existing code as a secondary test.
Perhaps a simpler way to test this is to check that each row date is greater than or equal to the previous row date. Just one compare per row instead of two+. When you reach a row date that fails this test, you then need to “look around” to decide whether the “blame” is with the previous row or with the current row. It doesn’t matter how fast this “look around” code is because it will only be used in the error situation.