Discussion :

[lefju cabro]

Bonjour,

J'ai une classe "TMaClasse" avec une propriété "FIsLocked":

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
TMaClasse = Class(TForm)
  private
    ...
    FIsLocked: Boolean ;
  public
    ...
  end;

Dans la classe définie ci-dessus, je veux qu'en modifiant la valeur de FIsLocked, un événement soit lancé afin d'activer/désactiver des composants de ma fiche. Est-il possible d'affecter un évènement directement sur une propriété ?
Je ne crois pas qu'il soit possible de le faire et mes recherches ne m'ont pas donné de réponses.

Ce problème n'est pas bloquant mais ma curiosité me pousse à vous demander.

Merci pour votre aide

[rsc]

Si j'ai bien compris ta question, c'est le mécanisme même des propriétés et des méthodes d'accès

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
TMaClasse = Class(TForm)
  private
    ...
    FIsLocked: Boolean ;
  protected
    procedure SetIsLocked(const Value: Boolean);
  public
    property IsLocked read FIsLocked write SetIsLocked;
    ...
  end;
 
implementation
 
procedure TMaClasse.SetIsLocked(const Value: Boolean);
begin
  FIsLocked := Value;
 
  // Là le code qui doit modifier tes composants
end;

Et quand tu fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

IsLocked := True ;// ou False

ta procédure s'exécute.

[lefju cabro]

Bonjour rsc,

Merci pour ta réponse.

J'avais effectivement cette solution en tête mais je rêvais plus d'une méthode avec un évènement de type OnChange sur ma propriété FIsLocked.
Je doute que cela soit possible sur une variable Boolean.

Merci

[rsc]

Un événement, c'est une propriété, donc on ne peut pas affecter un événement à une propriété.

Tu peux, si tu peux faire déclencher un événement par la modification de ta propriété. Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
TMaClasse = Class(TForm)
  private
    ...
    FIsLocked: Boolean ;
    FOnLock: TNotifyEvent;
  protected
    procedure SetIsLocked(const Value: Boolean);
  public
   procedure MaClasseLock(Sender: TObject);
   property IsLocked read FIsLocked write SetIsLocked;
    property OnLock: TNotifyEvent read FOnLock write FOnLock;
    ...
  end;
 
implementation
 
procedure TMaClasse.MaClasseLock(Sender: TObject);
begin
  // Ton code...
end;
 
// Dans le OnCreate de la fiche
  FOnLock := MaClasseLock;  
 
procedure TMaClasse.SetIsLocked(const Value: Boolean);
begin
  FIsLocked := Value;
 
  if (Value = True) and Assigned(FOnLock) then
    FOnLock(Self);
end;

C'est un procédé qui peut-être très utile lors de la création d'une classe, dans la mesure où cela permet aux utilisateurs de ta classe de définir leurs propres gestionnaires d'événements.
Mais dans ton cas, à part rajouter de la complexité...

[lefju cabro]

Merci pour la réponse.
Même si dans mon c'est inutile, c'est ce que je recherchais !!
Merci

[rsc]

Si c'est bon pour toi, n'oublie pas d'ajouter au fil de discussion la balise "Résolu"
et bon courage pour la suite !

[erca57]

Pour pouvoir y associer un évènement, il suffirait que le type de la propriété FIsLocked soit une classe dans laquelle serait défini un évènement OnChange, non ?

[rsc]

Techniquement, oui, tu pourrais alors écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

FIsLocked.On Change := <Mon gestionnaire d'événement>;

Mais d'une part, ça ne simplifiera pas l'écriture, d'autre part, conceptuellement, tu perds la sémantique de ta propriété IsLocked ("C'est verrouillé, c'est déverrouillé"), puisque ce n'est plus un booléen, mais un objet. Et l'expérience prouve que ce qui est conceptuellement faux est toujours source de problème

Ceci dit, ce n'est pas défendu d'essayer

[octal]

A mon avis ce que tu cherche à faire est impossible directement. Il faudra cacher ta variable membre derrière une propriété, et faire tout les changement sur la variable membre via des méthodes (getter/setter). C'est méthodes là déclencheront un évènement OnChange() dans le cas où celui ci est affecté (if Assigned(OnChange) ) ...

Ce que tu cherche à faire nativement c'est de déclencher un évènement qd l'état interne de ton objet change (l'une des variables membre change). Cela n'est pas possible en Delphi (du moins jusqu'à D2009. Je sais pas si en D2010 c'est possible ou pas, faudra vérifier).
Ce genre de chose est facilement implémenté en Java (et récement en C#4) via ce que l'on appelle les Property Change Listeners. Ce sont des évènements que l'on implémente et que l'on accroche à une ou plusieurs propriétés, et ils se déclenchent dès que l'une de ces propriétés change d'état.
Et oui, Delphi est bien en retard quand il s'agit d'implémenter certains pattern (pourtant bien utiles). Il faudra souvent bidouiller pour faire ce que Java faisait nativement depuis plus de 15 ans.

[rsc]

Ce genre de chose est facilement implémenté en Java (et récement en C#4) via ce que l'on appelle les Property Change Listeners. Ce sont des évènements que l'on implémente et que l'on accroche à une ou plusieurs propriétés, et ils se déclenchent dès que l'une de ces propriétés change d'état.
Et oui, Delphi est bien en retard quand il s'agit d'implémenter certains pattern (pourtant bien utiles). Il faudra souvent bidouiller pour faire ce que Java faisait nativement depuis plus de 15 ans.

Je ne saisis pas bien la différence avec les accesseurs de propriétés dont je parlais plus haut (SetIsLocked), qui "se déclenchent dès que la propriété change de valeur" .

[octal]

Je ne saisis pas bien la différence avec les accesseurs de propriétés dont je parlais plus haut (SetIsLocked), qui "se déclenchent dès que la propriété change de valeur" .

Si ta propriété change SANS PASSER par les accesseurs ca ne marchera pas. Ton exemple est trop simpliste. Imagine que ton objet change ta variable membre sans passer par la propriété soit dans d'autres routines, soit parce qu'un client intelligent réutilisant ton code hérite de ton objet et fait que le descendant cache ou modifie cette variable membre sans appeler les accesseurs.
Pire encore, en Delphi (si on n'utilise pas les extensions STRICTE du D2007 et ++) les varables membres privées ne sont privées que pour l'unité en cours, donc tous les objets déclarés dans ton Unit ont un accès publique à tes var membres même si celle ci sont déclarées privées. Tous cela pourra faire que lors de modifications future du code, tes "suppositions sur le mode de fonctionnement" tomberont à l'eau. Quand on développe, les bonnes pratiques veulent qu'il faut rester déterministe.

Cela n'est pas le cas en Java avec les Event Listeners. Ceux ci se déclanche dès que l'état de ton objet change, indépendement de l'outil ou de la méthode ou de l'objet qui a modifié l'état.

[Kaféine]

Je pense que tous ce qui existe en java peut être implémenté en Delphi

[rsc]

Si ta propriété change SANS PASSER par les accesseurs ca ne marchera pas. Ton exemple est trop simpliste. Imagine que ton objet change ta variable membre sans passer par la propriété soit dans d'autres routines, soit parce qu'un client intelligent réutilisant ton code hérite de ton objet et fait que le descendant cache ou modifie cette variable membre sans appeler les accesseurs.

C'est bien pour cela que le champ est déclaré en private, et la propriété en public (ou protected, ou published), ce qui force tout utilisateur de ton objet à passer par les accesseurs.

Ca me semble assez logique et propre, même si comme toi, j'ai toujours trouvé illogique la possibilité d'outrepasser le private quand on reste dans la même unité.

Maintenant, il me semble que dans la mesure où un utilisateur a accès à ton unité source et, dans le cadre d'un héritage, estime intelligent de la modifier et de passer par-dessus les visibilités... soit il sait ce qu'il fait, soit je suppose que même en Java, on ne peut pas protéger les gens contre eux-mêmes.

Mais le but n'est pas ici de dire qu'un langage vaut mieux qu'un autre, mais d'aider notre ami

[octal]

C'est bien pour cela que le champ est déclaré en private, et la propriété en public (ou protected, ou published), ce qui force tout utilisateur de ton objet à passer par les accesseurs.

Ca me semble assez logique et propre, même si comme toi, j'ai toujours trouvé illogique la possibilité d'outrepasser le private quand on reste dans la même unité.

Maintenant, il me semble que dans la mesure où un utilisateur a accès à ton unité source et, dans le cadre d'un héritage, estime intelligent de la modifier et de passer par-dessus les visibilités... soit il sait ce qu'il fait, soit je suppose que même en Java, on ne peut pas protéger les gens contre eux-mêmes.

Mais le but n'est pas ici de dire qu'un langage vaut mieux qu'un autre, mais d'aider notre ami

Je ne veux en aucun cas soulever le débat stérile de la suprématie d'un langage vis à vis d'un autre (le meilleur language est celui que l'on maitrise et qui nous permet de régler un pb X au moment t).
J'ai mentionner Java et les Property Change Listeners juste pour mettre en avant que ce genre de problèmes est fréquent et qu'il a une solution élégante dans des languages autres que Delphi. Mentionner de telles infos permet de mieux guider les développeurs et leur permet d'avoir plus de mots clés ciblés pour améliorer leur recherches sur Google ou sur les forums.

Pour ce qui est du Public/Privé je suis d'accord sur le principe de la discipline et du passage obligé par le Public dans les classes externes, mais imagine que c'est ton objet lui même qui change la variable membre indirectement!!! Soit en modifiant la variable membre dans une expression, soit via des fonctions manipulant des pointeurs (c'est le cas par exemple des classes utilisant du hardware pour changer leur état interne, comme c'est le cas des classes qui implémente la réception sur des ports COM ou Eth). Cela peut toujours arriver. Je ne dis pas que la solutions des accesseurs ne soit pas bonne, c'est l'une des solutions communément utilisées dans Delphi mais ce n'est pas une solution générale à ce genre de problème parce que l'exemple pris est trop simpliste. Si ta variable membre était un pointeur sur une classe instanciée dynamiquement, tu ferais comment? il faudra bidouillé dans la classe membre pour faire remonter l'info... tout ce genre de détails auraient été réglé d'une manière élégante si Borland (CodeGear ou Embarc....) avait implémenté les EventListeners et les PropertyChange Listeners correctement. Je ne sais pas si ça n'a pas été fait en D2010, mais dans les versions d'avant cela était délicat parce que delphi ne proposait aucune interface RTTI (de reflexion) "documentée" et officielle. Cela a changé avec D2010 mais je ne sais pas si les Listeners ont été implémentés ou pas (je ne travaille plus sur des projets impliquant Delphi).

Cordialement