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:
- Switch editing on and off in the options of the grid (TDBAdvGrid.Options.goEditing e.g.)
- 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…