Composant edit permettant de savoir qui a modifie le texte dans le onchange

Soyez le premier à donner votre avis sur cette source.

Vue 3 738 fois - Téléchargée 548 fois

Description

Ce composant permet de connaitre la source de l'evennement OnChange (provoque par une modification de l'utilisateur ou par le code).
Il propose 3 evenements :
OnUserChange est appelé lors d'une modification par l'utilisateur
OnCodeChange est appelé lors d'une modification par le code
OnChange qui est appelé lors de toute modification et qui precise la source (Event spécial)
Son utilisation est assez simple, un projet d'exemple est fourni avec.
Le composant est ajouté à la palette "Edits".

Si vous avez des questions ...

Conclusion :


j'ai relaisé ce composant par rapport à un sujet du forum :
http://www.delphifr.com/infomsg_CONNAITRE-ORIGINE-ACTION-SUR-COMPOSANT-UTILISATEUR-OU-CODE_829669.aspx

Codes Sources

A voir également

Ajouter un commentaire

Commentaires

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
4200
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
13 juin 2020
30
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 :$
Messages postés
4580
Date d'inscription
samedi 19 janvier 2002
Statut
Modérateur
Dernière intervention
9 janvier 2013
27
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 ?
Afficher les 6 commentaires

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.