EditRowNotify

EditRowNotify() Event

Called when editing a new row

Applies to: Grid

Introduced in KCML version 6.00

EditRowNotify

The EditRowNotify() event can be used to implement efficient editing of a grid for the very common case where each row of the grid corresponds to a row in a database. The TabThrough property must be set, and will control tab navigation through the grid. Cells to be edited will use the AutoEdit properties.

The following properties are always set when the EditRowNotify() event is entered:

Notes:

• The EditRowNotify() event is called whenever the user starts or ends editing a row. If the user ends editing a row and starts editing a new row, then a single EditRowNotify() event is generated. The last cell being edited is specified by the CursorRow and CursorCol properties. If there is no current edit cell then these properties will be 0. If a new edit cell will be started, its position will be found in NewRow and NewCol. If there is no new edit being started, then these properties will be 0.
• The CursorRow and NewRow properties can be used to control the locking of rows in a database. If a row is starting to be edited then the row will be locked (and maybe refreshed) and when the row edit is ending it will be written and unlocked. The NewRow of one call to EditRowNotify() will always become the CursorRow of the next call (provided the event handler does not cancel the edit).
• Operations that terminate a row edit include tabbing to another row on the grid, tabbing off the grid, clicking on another row of the grid or another control altogether. If the form terminates then an EditRowNotify() event is generated. If the user tabs to a cell on the grid that is not AutoEdit, then an EditRowNotify() event is generated even if cell is on the same row as the last edit.
• The EditValidate() event may be used to validate cell edits and will always be generated first. If the validate fails then the cursor will remain in the current edit cell, and so no EditRowNotify() is generated at this point.
• It is possible to modify the layout of a grid inside a EditRowNotify() event and provoke a further event (or several). For instance, if editing a grid, the user tabs out of editing the very last cell of a grid. The EditRowNotify() handler could add another line to the grid and make it editable. On return from the event handler, the tab operation will be tried again from the edit cell, and this time will move onto the new row for the grid. In this second call, CursorRow will be 0 as the previous edit ending had already been notified.
• The grid's MoveCursor() method and the general SetFocus() methods may be used inside an EditRowNotify() event handler. Both these methods stop the new edit from starting; there will be no subsequent EditRowNotify() event to say this edit has ended. If the MoveCursor() method is used, a subsequent EditRowNotify() event will be generated if the new cell is itself AutoEdit. It is also possible to use MoveCell(0, 0) to take focus off any particular cell. The next use of the tab key will place the cursor on the first permiited cell on the grid.
• If there is a right click event handler, then the right click will terminate the edit, generating an EditRowNotify() event followed by the RightClick event.
• There are three circumstances where the edit may be terminated by a cancelling action. In all three cases the CancelEdit property will be TRUE. In all other cases it will be FALSE. These circumstances are:
  • The user clicks Cancel. The EditRowNotify() event will be generated before the Cancel Click event.
  • The user hits the Escape key and there is a Cancel button. The EditRowNotify() event will be generated before the Cancel button Click event.
  • The user hits the Escape key, but there is no Cancel (or it is not visble or enabled) button on the form. The EditRowNotify() is generated but the form will not be terminated.
  In all cases any changes to a cell being edited will be lost, and no validate events will occur.

See also

Grid methods, properties and events.