Firstly, a couple of new properties have been implemented that allow you to set limits on the number of rows a user can add or remove from the EditTable via the keyboard: These are the MAXROWLIMIT and MINROWLIMIT properties.
When MAXROWLIMIT is set the user cannot use the Insert key to insert more rows than the number specified by this property. The default value is “0”, which means there is no maximum limit. Note that this property does not apply to programmatic INSERT method operations or data set by the LIST or ARRAY properties.
When MINROWLIMIT is set the user cannot use the Delete key to delete EditTable rows once the minimum limit has been reached. The default value is “0”, which means there is no minimum row limit. Note that this property does not apply to programmatic DELETEmethod operations or data set by the LIST or ARRAY properties.
Blocking the “Insert” and “Delete” keys
Previous versions of the EditTable allowed you to set a “Protected” property at design time that stopped all row insert and delete operations by the user. Unfortunately, this was not actually exposed run-time (unless you adjusted a bit-flag the control’s STYLE property), so in version 10 we’ve expanded the old “Protected” property into two new properties called ALLOWROWDELETE and ALLOWROWINSERT. These can used at both run-time and design-time.
When set to False the user cannot use the Delete key to delete rows within an edit table. The default value of this property is True.
When set to False the user cannot use the Insert key to insert new rows within an edit table. The default value of this property is True.
Managing the “Insert” and “Delete” keys
Finally, we made some changes to the way the actual inserts and deletes take place to give you an opportunity to intercept them for even more control. In previous versions of OpenInsight the EditTable notified you of an insert or delete operation after it had taken place, via the INSERTROW and DELETEROW events respectively. This means that if you wanted to ‘prevent’ the modification based on some run-time criteria you had to effectively undo it, which usually included some sort of unpleasant visual effect as the insert or delete was rolled back (it also resulted in a loss of formatting information or other cell-specific data that you would have to reapply).
In version 10 we’ve added a new Boolean property called ROWEVENTMODE. When set to False (the default) row insertion and deletion via the keyboard behaves in exactly the same way as previous versions of OpenInsight. When set to True however, the INSERTROW or DELETEROWevent happens before the actual operation takes place, and at this point you can do the following:
- If you’re using an EventScript you can return FALSE$ and the operation will be cancelled.
- If you’re using a code called from a QuickEvent you can set the EventStatus flag in your code to prevent the operation from proceeding further, just as you would currently do in a WINDOW CLOSE event to cancel it.
E.g. Stopping a row being deleted in a DELETEROW EventScript handler.
// Assumes "RowEventMode" is "True" // // Check to see if there is anything in column 2 of the deleted data, // and if so stop the delete via the event return value. $insert logical if bLen( rowData<2> ) then // Stop the delete retVal = FALSE$ end else retVal = TRUE$ end return retVal
E.g. Stopping a row being deleted in a DELETEROW QuickEvent handler
// Assumes "RowEventMode" is "True" // // Check to see if there is anything in column 2 of the deleted data, // and if so stop the delete via the Event Status $insert logical if bLen( rowData<2> ) then // Stop the delete call set_EventStatus( TRUE$ ) end return
Of course, once you’ve allowed the Insert or Delete operation to take place you may also want to do some post-processing, and for this we’ve provided two new events: INSERTEDROW and DELETEDROW. These have the same signature as their INSERTROW and DELETEROWcounterparts and are executed after the row modification has taken place (Note that these are only fired if the ROWEVENTMODE is True).
It is also worth noting that, as with previous versions of OpenInsight, using the DELETE and INSERT methods to programatically modify the EditTable contents will not trigger the INSERTROW or DELETEROW events (or any subsequent INSERTEDROW and DELETEDROWevents either).