The ultragrid doesn't seem to show the error provider (Red Indicators) beside the fields with broken rules.(I'm testing required fields right now).  I am getting the 'broken rules exist' message box but not the error provider indicators on the problem fields. 

I looked at the Business Binding Source example and it seems to work fine with the standard VS grid. 

Is there something I need to set on the UltraGrid to get this working?

Thanks

Tim

I'm not sure what the defaults are for the properties, but on the UltraGrid, we changed these properties:

Grid.DisplayLayout.Override.SupportDataErrorInfo = RowsAndCells
Grid.DisplayLayout.Override.DataErrorCellAppearance = {new appearance with .Image set to error icon}
Grid.DisplayLayout.Override.DataErrorRowAppearance = {new appearance with .Image set to error icon}

You can also change the background or foreground color of those appearances to get the cells/rows to stand out if they have errors.

Hi Ben,

Grid.DisplayLayout.Override.SupportDataErrorInfo = RowsAndCells fixed my problem.  Thanks.

Where is the best place to have row validation checked with the UltraGrid?. The validations work fine when I save the business object but I want to implement row validation, similar to a form. I tried adding some logic in the B/O Navigating event using the condition if me.BO.checkRulesOnCurrentRow(True)... but it doesn't seem to fire consistantly, nor does it display the errors,  when you navigate the grid.  I also tried using one of the Grid's events but the row indexes are not in sync with the business object so it make it tough to know if it's validating the correct information.

Any help would be great...

Thanks

TIm

The UltraGridRow object has a property called (I think) ListObject.  This property returns the reference to the backing data object of the row.  So, if you're binding through a BBS, then the ListObject property will return a reference to the business object, and that business object reference will be on the right row.  So, I would say to try using the grid events, but instead of calling CheckRulesOnCurrentRow(True) on the BO that you dropped on the form, cast the ListObject property as your business object type and call the CheckRulesOnCurrentRow(True) on it instead.

Ben,

I'm not having any success with showing broken rules on the current row of the grid or preventing the user from navigating away from the row until the broken rules are corrected.

Do you have an example of the code you are referring to in your post to cast the ListObject, plus any idea on how to prevent the user from changing rows until all the errors have been corrected?

Thanks,
Tim

I have also tried in the past to prevent a user from leaving the current row when there are broken rules, I have not found a way to do so.  With the IBindingListView interface (what the grid binds to), the only way to tell that the user changed the record is to attach to the CurrencyManager for the list and handle the PositionChanged event.  When that event fires, the record has already changed and I have been unsuccessful at changing the position back to another record within that event handler.

As for why the broken rules dot properly display, are you having problems finding the ListObject to cast it, or are the broken rules not displaying on the grid once you call the CheckRulesOnCurrentRow()?  I don't have a sample at the moment because we don't ever have to actually talk to the ListObject in this scenario... we just let all of the broken rules show for the whole business object when Save() is called.

You could add an Event for the ItemChangingFocus( I dont know exact event handler name ) of a Control and check the rule then and not move the control.   Has anyone implemented Field Level Checking versus Row Level Checking?

Richard 

This is called the Validating event of basically any control.  You can still implement this logic if you have the need.  As a side note, this is one of the options on when data will be updated back to the source OnValidation or OnPropertyChanged.  This is just FYI.  As for placing logic within a control to prevent the focus from being changed, you can handle or overwrite the OnValidating or OnLeave or something alone those lines to force validation before exiting.  Obviously, this will have to be handled within your code as the entire purpose of a BO business logic is to provide all of this at once versus on a field by field basis as you tab through.  This is an older technology and is what we did in our legacy systems.  There are few instances where we force the user to enter a field before moving on any longer.  The only time we take this approach is if other fields will rely on a value from the current field.