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); 
 if cbLocked.Checked then 
   gridAbilities.Options := gridAbilities.Options - [ goEditing ] 
  gridAbilities.Options := gridAbilities.Options + [ goEditing ]; 

This is 2:

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


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…

Tags: , ,
2 comments on “Flexibility of VCL and FMX programming …using events or properties
  1. Jon Robertson says:

    Although I agree with you about keeping the logic in a grid event rather than tied to another component outside the event, I expect CanEditCell could be called a lot more often, particularly if the user is scrolling around the grid cells with the keyboard.

    The edit state isn’t going to change unless the checkbox is changed. And I prefer not having code that is executed unnecessarily. Perhaps moving the code to the grid’s OnEnter event? It would still execute when there is no reason to change the state, but it would not execute nearly as often.

    • Holger Flick says:

      As far as I understand the documentation the “CanEdit”-event is only called when the user actually wants to edit the cell, i.e. by pressing F2, e.g. If you browse the grid with the cursor keys or click a cell with a mouse, there is no auto-edit (unless you implement it like that, of course).