Hi i have a grid bound to a datasource that support iDataErrorInfo
however whenever I turn on the
e.Layout.Override.SupportDataErrorInfo to cells or rows or rowsandcells
the grid performance becomes sluggish
restoring to SupportDataErrorInfo.None solves the problem, but i don't have the little red things anymore (naturally)
Each row has about 10 validation rules, simple ones, like not null or greater than 0
I am using net 2010.1 version 10.1.20101.1007
Hi Fred,
Who implemented the IDataErrorInfo interface? Is this a custom implementation of your own, or are you using a DataSet or some other data source?
The only reason I can think of why SupportsDataErrorInfo would slow the grid down is if your implementation of the interface is inefficient. For example, if you perform the validation on the data every time the IDataErrorInfo.Error property is accessed, then that would be a problem since the grid is going to hit this property quite a lot.
I'm pretty sure that the DataSet/DataTable implementation of this interface only performs validations when the data changes, and then it caches the error information so that when someone asks for the Error property, it's not doing anything but returning a string.
I am using the Entities generated with CodeSmith and NetTiers.
It is possible that there are not efficient.
I would have to look into that. If you tell me the problem is not on your end.. I will have to try and figure out more of the entities on my end I guess.
I can't be 100% certain of this without seeing the code and trying it out, and maybe running a performance profile. But applying an image to a cell is a very common thing and I know it's very efficient in the grid. So the only part of this that might be inefficient is determining whether there is an error or not.
If you want to whip up a small sample project demonstrating the performance problem, we would be happy to take a look at it and see if it's the grid or something else causing it.
I just started implementing this interface. I just return a string from a dictionary indexed by column name. I also do a check to see if BeginEdit has been called. If not, I return an empty string before I access the dictionary.
I'm not having a performance problem. However, I put Debug messages in my methods and there's an amazing amount of calls to this interface:
1. When the form loads, I get calls for every row and every property in that row, many, many, many times. I mean, the grid keeps asking for the same information several times. My grid is bound. No property changes have occurred. I expected to get one call per property, per row.
2. The grids loaded, I haven't clicked on any cells. I move my mouse pointer over the grid and I get several calls to this interface. This happens whether or not the grid has the focus or a row is selected.
Basically, it seems to me that the grid is making excessive, unnecessary calls to this interface. I mean, it needs to check once when its loaded. Then, until a property change notification is received, you can't have an error. Moving my mouse pointer is not a potential source for errors.
So...based on these observations, you do need an amazingly fast way to return a string or you may not even be able to move your mouse.
Mike, if you want to check this out, you just have add the IDataErrorInfo interface to any object that's bound to the grid, display a debug message when you get called and return an empty string.
I hope I'm doing something wrong. Please let me know.
Thanks,
Vincent
Hi Vincent,
vbivona said:I mean, it needs to check once when its loaded. Then, until a property change notification is received, you can't have an error. Moving my mouse pointer is not a potential source for errors.
While it is possible that there is some inefficiency in the way the grid is accessing the DataErrorInfo, the statement above is not correct. You are assuming that the constraints on the data are constant and never change, but the grid cannot make that assumption.
For example, suppose you have a grid column that displays a DateTime field and the values in that column must be between two other dates: a minimum and maximum. The minimum or maximum could be changed outside of the grid and that would affect the error information on every cell in the column.
Having said that, the scenario I described is probably not a very common case. And the grid would not update the error information until the next time the mouse moved over the cell or painted the cell for some other reason, anyway.
You are certainly correct that the current implementation assumes that your IDataErrorInfo implementation is very efficient.
And you are probably right and that the grid could be made more efficient by caching the errors and then exposing a way for the developer to refresh those errors when they need refreshing and no other changes have been made to the row. We would probably have to add a property like a DataErrorInfoMode or something so that you could specify whether or not the grid caches the errors or not.
I recommend that you Submit a feature request to Infragistics
Mike Saltzman"] Hi Vincent, I recommend that you Submit a feature request to Infragistics
Hi Mike,
I did realize why the grid has to do what it does and I don't see another way based the interfaces we have to work with. In fact, I have the situation that you described: In addition to the grid, I have a panel with some controls bound to the same dataset as the grid. There are a few situations where the grid and the text boxes are out of sync (concerning the error state). But, this is not the real case; I'm just learning about these interfaces before I implement them for real. The error state seems fine if I do all my editing in the grid though.
When I think about the whole thing, I'd really like to submit a request to Microsoft and ask for another interface, something like "INotifyDataError". Then, when bound controls receive this notification, they can update themselves.
Thanks very much for replying,
vbivona said:When I think about the whole thing, I'd really like to submit a request to Microsoft and ask for another interface, something like "INotifyDataError". Then, when bound controls receive this notification, they can update themselves.
Yeah, I agree that would make more sense.