COMPOSANT EDIT PERMETTANT DE SAVOIR QUI A MODIFIE LE TEXTE DANS LE ONCHANGE

Signaler
Messages postés
2226
Date d'inscription
dimanche 5 octobre 2003
Statut
Modérateur
Dernière intervention
18 novembre 2010
-
Messages postés
4580
Date d'inscription
samedi 19 janvier 2002
Statut
Modérateur
Dernière intervention
9 janvier 2013
-
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/39988-composant-edit-permettant-de-savoir-qui-a-modifie-le-texte-dans-le-onchange

Messages postés
4580
Date d'inscription
samedi 19 janvier 2002
Statut
Modérateur
Dernière intervention
9 janvier 2013
27
Parce que c'est inutile, cela est fait d'emblée : tout référent est automatiquement initialisé à Nil.
Ce n'est pas une faute, c'est seulement inutile...
Messages postés
991
Date d'inscription
samedi 25 octobre 2003
Statut
Membre
Dernière intervention
29 août 2013
5
pourquoi on ne met pas a nil les gestionnaires d'evenements?
Messages postés
4199
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
2 janvier 2019
29
on peu reduire les conditions

procedure TUserEdit.Change;
begin
inherited;
if Assigned(FOnChange) then
FOnChange(self, FUserEditing);

case FUserEditing of
false: if Assigned(FOnCodeChange) then FOnCodeChange(self);
true : if Assigned(FOnUserChange) then FOnUserChange(self);
end;
end;


on ne mets pas a nil les gestionnaire d'evenements!

constructor TUserEdit.Create(AOwner: Tcomponent);
begin
inherited;
FUserEditing := true;
end;


Set et Get doivent etre dans private et non dans protected.
Messages postés
991
Date d'inscription
samedi 25 octobre 2003
Statut
Membre
Dernière intervention
29 août 2013
5
non c'est bien volontaire.
En fait a la bas je suis parti uniquement sur les methodes propores à chaque source. Mais ensuite, je me suis dit que certains veulent peut etre plus faire un seul traitement avec quelques differences selon la source, comme par exemple:

Edit1Change(Sender: TObject; UserEdit: Boolean);
begin
if UserEdit then blablabla
//du code commun aux deux
if not UserEdit bliblibli
//du code commun aux deux
...
end;

c'est pour cela que j'ai implémenté la deuxième façon de proceder. il est donc preferable de ne pas melanger l'utilisation de ces 2 methodes, a moins d'etre sur de ce que l'on fait.
si on regarde le code, on voit bien que la methode OnChange est appelée avant les methodes OnUser/CodeChange. Donc il est possible de faire un traitement commun avant le traitement specifique.
Il est aussi possible de creer un evenement du style Before et After pour l'event commun.
Je pense qu'il est tout simplement plus simple de ne pas melanger les appels, mais je n'ai pas voulu le bloquer car quelqun qui sait quel est le processus d'appel peut en jouer.

desolé à ceux qui lise ce message, j'ai l'impression d'avoir dit 10 fois la meme chose de manieres differentes :$
Afficher les 6 commentaires