Hi,
I have a column in a grid column as a GridViewDecimalColumn where DecimalPlaces = 2, FormatString = "{0:#####,###,###,###,##0.##}"
This displays data correctly in all cases.
I am getting inconsistent behaviour though when I edit the cell depending on how the edit is started. This is a little difficult to explain, however :
Scenario 1 :
If I click in the cell so as to invoke the editor, the current value is displayed and fully selected and I am able to enter new data. The CellValueChanged event fires when I leave the cell if the data is valid. When CellEndEdit fires, it either has the new valid data, or the old value if invalid.
Scenario 2 :
If I highlight the cell but do not click to edit and press space, the same happens as above as the space keypress invokes the edit.
Scenario 3 :
If I just highlight the cell but do not click to enter edit mode and start typing, then cell editing begins. The CellValueChanged event fires immediately after the first keypress and the new value in this event is the value I typed, so If for example I enter "1", I now though get the following text in the cell
"1.00"
and the CellValueChanged value = 1
I can now enter text, however if I hit the decimal point and 2, I get a duplicate decimal point entered, so the cell contents are now "1.2.00" which is invalid.This happens for all scenarios and as the data is not valid I get no CellValueChanged event fired when I exit the cell. In scenarios 1 and 2, in CellEndEdit, when the new data is invalid, the event argument contains the original cell value before the edit. In scenario 3 though, as the CellValueChanged event fired on initial keypress, CellEndEdit now fires with 1 and not the old value.
I am looking really for a way to prevent entering multiple decimal points, or apply an edit mask to the cell to prevent invalid data entry. Also, I would ideally be looking for consistent behaviour for the 3 scenarios, so for the grid to reinstate the old value (pre-edit value) in all cases when the data is invalid and not the first valid value as in scenario 3.
Cheers,
I have a column in a grid column as a GridViewDecimalColumn where DecimalPlaces = 2, FormatString = "{0:#####,###,###,###,##0.##}"
This displays data correctly in all cases.
I am getting inconsistent behaviour though when I edit the cell depending on how the edit is started. This is a little difficult to explain, however :
Scenario 1 :
If I click in the cell so as to invoke the editor, the current value is displayed and fully selected and I am able to enter new data. The CellValueChanged event fires when I leave the cell if the data is valid. When CellEndEdit fires, it either has the new valid data, or the old value if invalid.
Scenario 2 :
If I highlight the cell but do not click to edit and press space, the same happens as above as the space keypress invokes the edit.
Scenario 3 :
If I just highlight the cell but do not click to enter edit mode and start typing, then cell editing begins. The CellValueChanged event fires immediately after the first keypress and the new value in this event is the value I typed, so If for example I enter "1", I now though get the following text in the cell
"1.00"
and the CellValueChanged value = 1
I can now enter text, however if I hit the decimal point and 2, I get a duplicate decimal point entered, so the cell contents are now "1.2.00" which is invalid.This happens for all scenarios and as the data is not valid I get no CellValueChanged event fired when I exit the cell. In scenarios 1 and 2, in CellEndEdit, when the new data is invalid, the event argument contains the original cell value before the edit. In scenario 3 though, as the CellValueChanged event fired on initial keypress, CellEndEdit now fires with 1 and not the old value.
I am looking really for a way to prevent entering multiple decimal points, or apply an edit mask to the cell to prevent invalid data entry. Also, I would ideally be looking for consistent behaviour for the 3 scenarios, so for the grid to reinstate the old value (pre-edit value) in all cases when the data is invalid and not the first valid value as in scenario 3.
Cheers,