cs_Delphiprog
Messages postés4297Date d'inscriptionsamedi 19 janvier 2002StatutMembreDernière intervention 9 janvier 201332 23 oct. 2006 à 17:22
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...
Guillemouze
Messages postés991Date d'inscriptionsamedi 25 octobre 2003StatutMembreDernière intervention29 août 20136 23 oct. 2006 à 11:56
pourquoi on ne met pas a nil les gestionnaires d'evenements?
f0xi
Messages postés4205Date d'inscriptionsamedi 16 octobre 2004StatutModérateurDernière intervention12 mars 202235 23 oct. 2006 à 06:20
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.
Guillemouze
Messages postés991Date d'inscriptionsamedi 25 octobre 2003StatutMembreDernière intervention29 août 20136 21 oct. 2006 à 23:09
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 :$
cs_Delphiprog
Messages postés4297Date d'inscriptionsamedi 19 janvier 2002StatutMembreDernière intervention 9 janvier 201332 21 oct. 2006 à 22:31
Il y a un petit point qui me gêne. Si l'on assigne une méthode à OnChange et à OnUserChange (ou à OnChange et à OnCodeChange), alors ces deux routines seront appelées. Est-ce volontaire ou bien il manque un "else" quelque part ?
JulioDelphi
Messages postés2226Date d'inscriptiondimanche 5 octobre 2003StatutMembreDernière intervention18 novembre 201014 20 oct. 2006 à 14:49
fonctionne tres bien, super utile ce genre de compo :D
bravo
23 oct. 2006 à 17:22
Ce n'est pas une faute, c'est seulement inutile...
23 oct. 2006 à 11:56
23 oct. 2006 à 06:20
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.
21 oct. 2006 à 23:09
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 :$
21 oct. 2006 à 22:31
20 oct. 2006 à 14:49
bravo