Flexibility of VCL and FMX programming …using events or properties

The following example might seem rather trivial, but I could not help but think about if there was a downside to any of the two….

Here’s the example: I have a grid that allows the data in it to be edited. Furthermore, I added a checkbox to the form that is to make the grid read only when checked:

Reason for this is that I do not want to get into edit mode by accident.

Basically, I have to options:

1. Switch editing on and off in the options of the grid (TDBAdvGrid.Options.goEditing e.g.)
2. Look for an event like BeforeEdit or CanEditCell and (dis-)allow editing there

This is 1:

procedure TFrmAbilities.cbLockedClick(Sender: TObject); 
begin
 if cbLocked.Checked then 
   gridAbilities.Options := gridAbilities.Options - [ goEditing ] 
 else
  gridAbilities.Options := gridAbilities.Options + [ goEditing ]; 
end;

This is 2:

procedure TFrmAbilities.gridAbilitiesCanEditCell(Sender: TObject;
  ARow, ACol: Integer; var CanEdit: Boolean);
begin
  CanEdit := (ACol > 0) AND (not cbLocked.Checked);
end;

In hindsight, I do not like messing with sets in my code (1) and (2) is much more to the point. I also like the fact that the functionality is encapsulated in the event of the grid and not in the Click-event of an grid-independent (and also unaffected by the datasource) control. Example (1) is something you find frequently as people like to put the business logic in the control that triggers an action.

I realy think implementing the event makes more sense and thus I kept that alternative. However, looking back at all the books I read on OOP, I really do think that none of the two code snippets violates any basic principles.

Happy to hear your two cents…