Validation Errors not cleared until edit

11 posts, 0 answers
  1. Brian Lam
    Brian Lam avatar
    28 posts
    Member since:
    Apr 2010

    Posted 07 Dec 2011 Link to this post

    My RadGridView is populated with items that have a structure like this:

    class ClassA
    {
        public ClassB classB;
    }
     
    class ClassB : INotifyDataErrorInfo
    {
        public string ID;
    }

    The ItemsSource of the RadGridView is filled with ClassA objects, and the columns are bound to properties of ClassB, so their binding paths are something like "classB.ID". If ClassB.ID has a validation error when the grid is populated, the cell is initially shown with the red validation error box around it. However, if the validation error is cleared, the cell doesn't remove the validation error box until the cell is put in edit, even though ClassB raises the ErrorsChanged event immediately.

    I read another post describing a similar problem (http://www.telerik.com/community/forums/silverlight/gridview/data-validation-errors-not-shown.aspx), and the response said that the columns don't listen to "custom" bindings for validation error notification for performance reasons. This is unacceptable behavior because the cell shows validation errors from "custom" bindings in some cases (i.e. if there's an error when the grid is initialized, or if the error results from a user editing the value in the cell), but not others (i.e. if an outside processes clears the validation errors). A performance optimization isn't worth having incorrect behavior in the grid.

    The grid is already doing all the work of finding the owner of the property and asking it whether there are errors or not, so why can't it also subscribe to the ErrorsChanged event of that owner?
  2. Dimitrina
    Admin
    Dimitrina avatar
    3769 posts

    Posted 12 Dec 2011 Link to this post

    Hello Brian Lam,

     I see your point, but lets say that the custom binding is on 5 levels. We will have to listen for all the 5 events. This will decrease the performance very much, which is not acceptable.


    If you raise the ErrorsChanged for the ClassA object, then everything will be updated fine.

    Regards,
    Didie
    the Telerik team

    Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>

  3. DevCraft banner
  4. Brian Lam
    Brian Lam avatar
    28 posts
    Member since:
    Apr 2010

    Posted 12 Dec 2011 Link to this post

    Hi Didie,

    I'm not suggesting that the grid should listen to all intermediate objects in the binding path, but it should at least be listening to the parent object of the property that the column is bound to. The column is already asking that parent object for the errors in the cell, so it's already figuring out who the correct parent object is when the column is bound to a "complex" path.

    For example, if a column is bound to "ClassA.ClassB.ClassC.ClassD.Description", then ClassD is the parent of the Description property, and it should be asked when Description has an error. There's no reason to listen to the ErrorsChanged event of ClassA/ClassB/ClassC for that column.

    Have you internally tested this scenario and seen the grid's performance degrade? If not, I think it would be much better to have the cells listen to the appropriate parent object than just waiting for the row-level item to raise the ErrorsChanged event.
  5. Nedyalko Nikolov
    Admin
    Nedyalko Nikolov avatar
    871 posts

    Posted 15 Dec 2011 Link to this post

    Hi Brian Lam,

    Unfortunately the problem is not so simple. I'll try to clarify a little bit. The problem comes from the fact that RadGridView does not listen for any binding validation errors due to some visual issues and there is no way to update cells on every errors change (when bound to a nested property only). RadGridView reads these binding errors when preparing cell's content. Therefore every cell refresh (like scrolling out and return, sorting, grouping and so on) will update cell's invalid state accordingly. We are doing our best in order to improve this behavior for the next official release (2011.Q3.SP1).

    All the best,
    Nedyalko Nikolov
    the Telerik team

    Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>

  6. Brian Lam
    Brian Lam avatar
    28 posts
    Member since:
    Apr 2010

    Posted 15 Dec 2011 Link to this post

    Hi Nedyalko,

    I'm a little unclear on what you meant in your post. Are you saying that the Q3 2011 SP1 release will listen to validation errors on nested properties, or are the improvements unrelated to this?
  7. Nedyalko Nikolov
    Admin
    Nedyalko Nikolov avatar
    871 posts

    Posted 15 Dec 2011 Link to this post

    Hi Brian Lam,

    Yes this is what I meant. RadGridView will listen for validation errors on nested properties with upcoming 2011.Q3.SP1 release.

    Kind regards,
    Nedyalko Nikolov
    the Telerik team

    Explore the entire Telerik portfolio by downloading the Ultimate Collection trial package. Get it now >>

  8. Brian Lam
    Brian Lam avatar
    28 posts
    Member since:
    Apr 2010

    Posted 15 Dec 2011 Link to this post

    Great, I'll retest the issue when that release comes out and let you know how it goes. Thanks!
  9. Chris Sterner
    Chris Sterner avatar
    5 posts
    Member since:
    Oct 2007

    Posted 12 Jun 2013 Link to this post

    I am working on the same project that the OP, Brian Lam, posted about.  I am seeing a very similar problem occur again, so I am resurrecting this thread so you can have the original context he provided.

     

    When we took 2011 Q3 SP1, this fixed most of our problems with the validation error box not going away.

     

    However, in version 2012 Q1 SP1 (2012.1.326.1050) we noticed another problem.  The problem may have occurred before that version.  When validations were cleared by something other than the user editing in the grid, the grid would not clear the validation error box.  The grid did not seem to re-evaluate its validation visual state when the PropertyChanged and ErrorsChanged fired on ClassB.  I was able to get around this behavior by calling Rebind on the GridViewDataControl to get it to re-check for validation errors.  I am calling Rebind every time that validation errors change.

     

    This Rebind approach was working in version 2012 Q3 SP1 (2012.3.1129.1050).  But we have recently upgraded to 2013 Q1 SP1 (2013.1.0403.1050), and are noticing this Rebind approach is no longer catching all changes in validation errors.  Let me describe two scenarios we see.

     

    The first scenario involves editing data directly in the grid.  We have a validation requiring that the value in a column (Keyword) must be unique.  Let’s say we have two rows, 1 and 2, and the Keyword value can be A,B,C,D.  To start with, let’s say there is a sort on another column which will not change, so the rows data will not swap.

    1. When 1=A and 2=A, both rows have red validation error backgrounds as expected.
    2. When you change 1=C, 1 loses the error but 2 remains red.  This is not correct as both rows lost their validation errors according to the backing data model.
    3. If you then change 2=B, 2 then notices it is no longer in error and loses its red validation error background.

     

    The next scenario involves editing data outside the grid.  Say we have another grid bound to the same data as in the first scenario.  

    If there is a sort on another column which will not change, then the behavior is the same as the first case.

    1. When 1=A and 2=A, both rows have red validation error backgrounds as expected.
    2. When you change 1=C, 1 loses the error but 2 remains red.  This is not correct as both rows lost their validation errors according to the backing data model.
    3. If you then change 2=B, 2 then notices it is no longer in error and loses its red validation error background.

    If there is an ascending sort on the Keyword column of the grid not being edited directly, then the behavior is slightly different.  Again, we are changing the data in the first grid and observing the changes in a second grid.

    1. When 1=A and 2=A, both rows have red validation error backgrounds as expected
    2. When the first row of the first grid is changed to C, that causes the second grid to swap the changed row to its second row.  Now the second grid shows no error on the first row (A), but shows an error on the second row (C the one that had its data changed).
      1. At this point if you change the sort of the second grid, the second grid will keep the red error background on the second row no matter what data is in it.
    3. When you change the second row of the first grid from A to B, the error indicator does not go away on the second grid on its C row.
    4. If the first row is changed from C to D, the error indicator will finally go away in the second grid.

     

    The second scenario is a bit confusing to follow.  But I think it shows that when rows are being moved around by sorting, there is some additional problem happening.

     

    In the past, the following code, called when validation errors where added or removed from anything, was a brute force way to avoid these problems,  InnerGridView is the GridViewDataControl,

             void ValidationResults_CollectionChanged(object sender, NotifyCollectionChangedEventArgs e)

            {

                if (InnerGridView.RowInEditMode == null)

                {

                    //if we are not in edit mode, do a rebind to force grid to check if any validations changed

                    //do via dispatcher so we make sure to not renter ValidationResults.CollectionChanged event

                    Dispatcher.BeginInvoke(() =>InnerGridView.Rebind());

                }

                else

                {

                    //if we are editing something, wait until it is done then Rebind()

                    //this is because Rebind() will cause use to stop editing, which is an annoying UX if you are in the middle of editing

                    EventHandler<GridViewRowEditEndedEventArgs> handler = null;

                    handler = (ss, ee) =>

                            {

                                InnerGridView.RowEditEnded -= handler;

                                Dispatcher.BeginInvoke(() => InnerGridView.Rebind());

                            };

                    InnerGridView.RowEditEnded -= handler;

                    InnerGridView.RowEditEnded += handler;

                }

            }

     

    Has there been a change in how validation errors are processed or how Rebind works?  If data has been changed outside of the grid, causing validations to change, how can we tell the grid to re-evaluate which rows should show the red validation error background?  Is there some way I can tell the grid exactly which rows are valid and invalid if they do not always work with INotifyDataErrorInfo?

     

    I do not have a simple example project to share that demonstrates this problem.

     

     Updated: corrected version numbers.

     

  10. Chris Sterner
    Chris Sterner avatar
    5 posts
    Member since:
    Oct 2007

    Posted 12 Jun 2013 Link to this post

    In looking thru the release notes for Q1 2013 (version 2013.1.0220), I notice these items,
    • Setting IsValid in RadGridView.RowValidating does not mark row as "invalid" when RadGridView.ValidatesOnDataErrors is set to "InViewMode"
    • Validation issue when ValidatesOnDataErrors is set to "InViewMode"
    • Fix for validation issue with ValidatesOnDataErrors = "None"
    • RadGridView does not show validation notification from INotifyDataErrorInfo (when invalid cell is not in view) with ValidatesOnDataErrors set to "InViewMode"

    So I should mention that our grids use GridViewValidationMode.InViewMode.

  11. Dimitrina
    Admin
    Dimitrina avatar
    3769 posts

    Posted 14 Jun 2013 Link to this post

    Hi,

    We have just released Q2 2013. Would you please test with that latest version?
    Then, if you can still reproduce the issues you have described, may I ask you to please open a support thread and attach a sample project to demonstrate the problems you have shared?
     

    Regards,
    Didie
    Telerik

    Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.

  12. Chris Sterner
    Chris Sterner avatar
    5 posts
    Member since:
    Oct 2007

    Posted 14 Jun 2013 Link to this post

    Upgrading from 2013 Q1 SP1 to 2013 Q2 does seem to correctly handle the cases I described.
Back to Top
DevCraft banner