Hello,
I'm trying to implement row/cell errors using IDataErrorInfo and I'm encountering some performance issues.The performance problem occurs on a column containing an EditorWithCombo with DropDownValidate style.I've set the column to be required (UltraGrid1OnBeforeExitEditMode event), and when I empty the value of the combobox (= select no value) it takes a really long time before the error is displayed. This compared to the string column which works immediately.
In attachment you will find an example solution. The CompanyEntity.CountryID property is displayed as a dropdown containing the specific countries.I expect the problem occurs because the country name (string) is attempted to be put in the CountryID field (integer).
You can reproduce the problem by starting the application, emptying one of the row's countryID column and then clicking on another row.
Any help on how to avoid this problem would be appreciated.
Kind regards,
Michael
PS: Version 12.1.2054
Hi Michael,
What's happening here is that the editor in the cell is converting DisplayText into DataValue. In this case, it's failing to do so, because there is no empty string on the list. So it's using an empty string as the Value of the cell and a whole bunch of exceptions end up getting raised. the exceptions are caught, but they cause causes a big performance hit.
If you are going to let the user blank out the cell, then you could alleviate the performance hit by adding a blank item to the list so that it matches up an empty string with a null (or DBNull.Value).
Hey Mike,
Thanks for the quick reply.
What if I want to not allow the user to blank out the cell, yet allow the user to type in the cell to easily search for a value ? How to I stop the user to blank out the cell or to type a value that is not in the list ? I tought the style "DropDownValidate" would cause that behaviour, but that doesn't seem to be the case.
Michael Mangelschots said:Is there no way to not allow the user to type a value that is not in the list ?
You could set the Style to DropDownList. In that case, the user cannot type into the cell at all, they can only choose from the list.
If you want the user to be able to type into the cell, then what you are asking is not possible, and I don't just mean in the grid, I mean it's logically contradictory. The user cannot type "Apple" without first typing "A" and if "A" does not exist, then they wouldn't be able to type it. So at some point, the user has to be able to type something that isn't on the list - at least temporarily. This is why DropDownValidate doesn't validate until the user tries to leave the cell.
The performance issue here stems from the fact that the grid is trying to convert the string value into a numeric and failing to do so. So one way you could potentially get around this is to use a column that is not a numeric type. You could use an unbound column, for example, whose DataType is object. That way, the column could accept a string and then you could use the IDataErrorInfo to display an error when the data is not numeric.
Mike,
Is there no way to not allow the user to type a value that is not in the list ?
Currently, in the example code I posted, every keystroke that would not result in a choice from the list, causes major performance issues. This is without the user exiting the cell. And when the field is exited an error messagebox is displayed "Unable to update the data vlaue: value in the editor is not valid.". This is undesirable behaviour.
I'm looking for a way to allow the user to type (= search in the list), without allowing the user to type in a value that not in the list. This without major lag between each keystroke and without a messagebox to be displayed. If there is an error in the cell, I want it to display the error icon.
How would I go about to realize that ?
DropDownValidate doesn't validate until the user tries to leave the cell. At that point, it will raise an error (assuming the data source does not allow nulls).
There's no way to both allow the user to type and also not let them blank out the cell while they are still in it. They would have to be able to blank out the cell in order to start typing into it.