The DataObjects for .NET concept of edit mode is exactly the same as in ADO.NET. A row is in edit mode after a BeginEdit method call. Calling EndEdit ends the edit mode state. Edit mode is intended for making successive changes to a row without validating the whole row. A single change does not have to satisfy validation conditions. Row validation occurs when the row exits edit mode, on EndEdit. Place such validation code in the BeforeEndEdit event.
Edit mode is used by bound controls: when a row becomes current, it is automatically placed in edit mode (BeginEdit is called implicitly). When the user moves to another row, the row exits edit mode (EndEdit is called implicitly). Bound controls maintain a single row in edit mode at any given time, it is the row corresponding to the current row position of System.Windows.Forms.CurrencyManager. Programmatic calls to BeginEdit / EndEdit allow multiple rows in edit mode simultaneously.
While a row is in edit mode, changes made to its fields since the moment it entered edit mode can be canceled (reversed) by calling CancelEdit. It can also be done through some bound controls, a grid, for example. The row remains in edit mode after CancelEdit, only field changes are canceled.
When a bound control or user code calls BeginEdit, DataObjects for .NET fires the BeforeBeginEdit. This event can be used to disallow transition to edit mode by throwing an exception, if necessary, although this is not a recommended design pattern. Note that transition to edit mode does not yet mean that the row is being changed. If you want to block changes to a row, the proper place to do it is in the BeforeFirstChange event, if you need to block the whole row, or in BeforeFieldChange, if you want to block a particular field.
After a row has entered edit mode, the AfterBeginEdit event is fired.
Before a row leaves edit mode, the BeforeEndEdit event is called. This event is the most important among the edit mode transition events, because it is the point where data validation code resides in most cases. If you have data validation rules dependent on multiple fields, program these rules in the BeforeEndEdit event. If validation rules are not satisfied, to signal validation failure, throw an exception. That will prevent row from leaving edit mode. Note that in many cases you can use Constraints, expressions specified as table or table view properties, instead of writing validation code in the BeforeEndEdit event. Record-level constraints are tested before the BeforeEndEdit event.
After a row has successfully left edit mode, the AfterEndEdit event is fired.
When the user cancels changes in edit mode (CancelEdit is called or a bound control cancels changes), DataObjects for .NET first fires the BeforeCancelEdit edit. Throwing an exception in that event disallows canceling changes. After successfully canceling, reversing the changes, DataObjects for .NET fires the AfterCancelEdit event.
Edit mode by itself does not mean that the row is being changed; it only signifies a special state in which changes to row fields do not trigger row validation. When the row is actually changed first time after entering edit mode, the BeforeFirstChange event fires. By throwing an exception in that event, you can disallow changes to the row. After the first change has been successfully performed, the AfterFirstChange event fires. You can use that event, for example, to show some user interface clues indicating that the row has been changed (canceling them in AfterCancelEdit and AfterEndEdit, if necessary). After the AfterFirstChange event has been fired for the first time, successive changes to row fields do not fire the BeforeFirstChange/ AfterFirstChange events.