Discussion :

[jcs2]

Comment résolvez-vous ce petit problème:

dans la procedure "..OnChange(.." on effectue un certain traitement que l'on ne veut pas voir exécuté au "TForm1.FormCreate" quand on initilalise le contenu du dit composant.

Existe-t'il un moyen autre que de mettre un booléen de type "if(FormCreate..) then exit;" de controle au début de la procedure "..OnChange(.."

[ShaiLeTroll]

Tu nous pose une question d'un devoir ! Très étrange formulation !
On dirait une question du test de FLX

Plusieurs méthodes,

1)
On n'affecte pas le OnChange dans l'inspecteur d'objet mais uniquement comme dernière étape du AfterConstruction !
C'est assez moche, on peut vite l'oublier et ré-associer les OnChange !

2)
On affecte le OnChange en DesignTime, on mémorise TNotifyEvent dans une variable locale AVANT de modifier le Control, on affecte à nil le OnChange, dans un try ... finally, on effectue le traitement, puis on réaffecte le TNotifyEvent mémorisé dans le OnChange
Cette seconde méthode a l'avantage d'être plus ouverte que la première !

3) Tester si TComponentState est à csLoading


PS :
Si tu utilises ma réponse pour un devoir scolaire, c'est bien cela t'apprend les astuces des développeurs expérimentés
Si tu utilises ma réponse pour un test de compétence pour un recrutement, euh change de métier !

[jcs2]

PS
Si tu utilises ma réponse pour un devoir scolaire, c'est bien cela t'apprend les astuces des développeurs expérimentés
Si tu utilises ma réponse pour un test de compétence pour un recrutement, euh change de métier !

Merci pour ta réponse ShaiLeTroll,

Non, non j'ai dépassé de loin l'âge d'aller à l'école, et je ne sollicite pas un emploi pour la simple raison que je suis à la retraite et que Delphi n'est pour moi qu'un simple passe-temps.
En fait j'utilise la méthode que je décris dans mon message, elle est simple, basique mais pas très élégante. J'espérais une solution simple et élégante à la fois.

[ShaiLeTroll]

La méthode 2) pour un FormCreate semble approprié !

La méthode 3) étant réservé à la création de nouveau composant comme dans le sujet [D2010] Surcharger l'évènement OnChange d'un composant héritant du TDateTimePicker


la méthode 2) donnerait en code

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
procedure TForm1.FormCreate(Sender: TObject);
var
  Remember: TNotifyEvent;
begin
  Remember := MonControl.OnChange;
  MonControl.OnChange := nil;
  try
    MonControl.Text := 'Une affectation qui provoque OnChange';
  finally
    MonControl.OnChange := Remember;
  end;
end;

Malheureusement, c'est typiquement, le truc qui reste bien dégueux, je me rappelle justement d'une discussion sur le forum sur le OnChange et le OnClick différent selon les composants, sur le TComboBox, par exemple, OnChange ne se produit que lors d'une modification par l'utilisateur mais pas sur une modification par code !

[jcs2]

Merci pour ce code,

Je vais l'essayer.
C'est quand même plus propre que le mien car on ne modifie pas la procédure "OnChange"

[Paul TOTH]

et tu peux bien évidemment créer une fonction pour cela

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
procedure SetEditValue(Edit: TEdit; const Value: string);
var
  Evt: TNotifyEvent;
begin
  Evt := Edit.OnChange;
  Edit.OnChage := nil;
  try
    Edit.Text := Value;
  finally
    Edit.OnChange := Evt;
  end;
end;

on dériver TEdit

Code :

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

1
2
3
4
5
 
type
  TEdit = class(StdCtrls.TEdit)
   procedure InitValue(const: Value: string);
  end;

[jcs2]

Merci aux experts seniors de ce site.

C'est d'ailleurs le livre de Paul Toth "Delphi 7 Studio" , qui m'a donné l'occasion et l'envie de me lancer dans des développements Delphi en 2002.

A la lecture du forum, il semble que beaucoup de membres continuent à utiliser Delphi 7. Quelle en est la raison principale? Serait-il une version majeure même par rapport à ses descendants?

[Paul TOTH]

Merci aux experts seniors de ce site.

C'est d'ailleurs le livre de Paul Toth "Delphi 7 Studio" , qui m'a donné l'occasion et l'envie de me lancer dans des développements Delphi en 2002.

A la lecture du forum, il semble que beaucoup de membres continuent à utiliser Delphi 7. Quelle en est la raison principale? Serait-il une version majeure même par rapport à ses descendants?

il y a eu un passage à vide avec le choix d'une orientation .Net, jusque Delphi 2009 il n'y avait pas bcp d'intérêt à quitter Delphi 7 pour faire du développement win32.

Avec 2009 est apparu le support Unicode (qui n'intéresse pas tout le monde)

XE2 propose le 64 bits, OSX et iOS...là encore ça n'intéresse pas tout le monde.

il y a des nouveautés dans le langage (generic, fonctions anonymes,...) des outils, mais le changement de version ne s'impose pas toujours.

en tout cas Embarcadero fait bcp d'efforts pour faire de XE2 la nouvelle version de référence.

[ShaiLeTroll]

Comme le disait Paul, il y a entre D7 et D2007, un grand nombre de version qu'il faut oublier, disons un égarement de 5 ans sur le .NET qui a été un fiasco !

Du coup, bcp sont restés en D7, et sauter en 2009, 10, XE ou XE2, avec l'Unicode, c'est un enjeu important, il faut racheter les libs externes, traquer l'utilisation de PChar\PAnsiChar partout dans le code pour prendre en compte le passage de ANSI à UNICODE

En pour ceux qui font juste des applications franco-française, devoir investir dans une migration pour gérer le chinois qui coûte sans que cela soit rentable et qui peut apporter des bugs imprévus ! Cela doit en refroidir plus d'un !
Bon après, il y en a certains qui achètent, migrent sans avoir pris cela en compte et qui pleurent car utilise encore le BDE\Paradox et une palanquée de technologie obsolète !

Mon ancienne boîte ne voulait pas évoluer, D7 serait la dernière version de Delphi, une des raisons de mon départ ! Maintenant je suis en BCB2007 et on migre en BCB XE2 !
Nous le 64Bits on l'attend pour BCB, les déploiements de nos logiciels (DCOM, WinService, DLL) commencent à être problématique car les Serveur 32Bits se font rares !