Discussion :

[stanislas]

Bonjour à tous ! Mon premier poste sur le forum Delphi car je viens de m'y mettre après plusieurs années dans le monde Java.

Je vous explique le soucis. J'ai un composant non visuel pour compresser décompresser des fichiers. Pour éviter de devoir le mettre dans plusieurs écran qui l'utilisent, je voulais avoir une classe qui à sa création va instancier ce composant, le rattacher à la fiche de provenance et gérer des méthodes utilitaires sur ce composant.

Exemple :
Ma Form :

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
 
type
  TfmRestaurer = class(TForm)
  ....
 
private
    ZipManager: TZipManager;
 
implementation
 
TfmRestaurer.OnCreate(Sender: TObject);
begin
    ZipManager := TZipManager.create(self);
end;
TfmRestaurer.OnBtClick(Sender: TObject);
begin
    ZipManager.compresser;
end;
 
end.

Ma classe TZipManager :

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
 
type
  TZipManager = class(TObject)
  private
     FZipComponent : TZipComponent;
  public
    procedure Compresser;
    constructor create(AOwner: TComponent);
implementation
 
constructor TZipManager.create (AOwner: TComponent);
begin
  FZipComponent := TZipComponent.create(AOwner);
  FZipComponent.fichierACompresser := 'LeFichier';
end;
 
procedure TZipManager.Compresser;
begin
  FZipComponent.compresser;
end;

Ce n'est qu'un exemple. Au constructeur, tout roule. Par contre quand j'appel ZipManager.Compresser ... ça plante sur FZipComponent.compresser; avec une erreur d'adressage memoire ...
Un problème de référence je pense mais il me semblait qu'en Delphi on n'était qu'avec des pointeurs vers des objet dans un cas comme celui ci ?
Ou alors comme le Composant appartient à une autre unitée ... alors il aime pas ?

Bref, si quelqu'un à une idée ...

[chaplin]

Code :

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

1
2
3
4
5
6
7
constructor TZipManager.create (AOwner: TComponent);
begin
  inherited create;
  FZipComponent := TZipComponent.create(AOwner);
  FZipComponent.fichierACompresser := 'LeFichier';

end;

Comme tu as surchargé le constructeur, il ne faut pas oublier d'appeler le construteur original.
D'ailleurs, il faudra aussi overrider le desctructeur:

Code :

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

1
2
3
4
5
destructor TZipManager.Destroy;
begin
   FZipComponent.free;
   inherited Destroy ;
end;

En fait je me demande, si c'est pas plus simple de faire une classe dérivée TZipManagerAffectedNameFile de TZipManager. Je vois pas m'interêt de le mettre dans un autre une classe.

[stanislas]

Merci, effectivement je n'avais pas appelé le constructeur de TObject mais ça ne résoud pas le problème ...
Je ne vois pas trop ce que tu veux dire faire une classe dérivée de TZipManager, tu veux peut-être dire une classe dérivée de TZipComponent ?
Je me demande si c'est pas que je ne remplis pas certains paramètre essentiels de mon composant, comme le nom par exemple !

[Kaféine]

Salut,

je voulais avoir une classe qui à sa création va instancier ce composant, le rattacher à la fiche de provenance et gérer des méthodes utilitaires sur ce composant

pourquoi le rattacher à la fiche vu qu'il est non visuel?
pourquoi ne pas directement instancier TZipComponent?

ou alors créer un wrapper avec une interface pour bénéficier de la libération automatique de la mémoire...
je ne comprend pas l'interet de la classe TZipManager, mais bon peut être que quelque chose méchappe.

[chaplin]

Code :

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

1
2
3
4
5
6
7
8
9
10
type
  TZipManager = class(TObject)
  ...
constructor TZipManager.create (AOwner: TComponent);
begin
  inherited create;
  FZipComponent := TZipComponent.create(AOwner);
  FZipComponent.fichierACompresser := 'LeFichier';

end;

Tu utilises une classe TObject qui manipule un TComponent, c'est louche au niveau du constructeur que d'utiliser un autre TComponent en guise de classe chargé de sa destruction quand elle appartient à TZipManager.

Je voulais dire TZipComponent au lieu deTZipManager

[stanislas]

Alors, pour donner l'utilité de mon TZipManager c'est surtout d'avoir des méthodes utilitaires qui s'appuient sur mon composant TZipComponent qui vont être réutilisées dans l'application.
En fait, ce serrait pas un composant ça m'arrangerait presque J'avoue avoir du mal à comprendre l'intéret d'un composant non visuel. Pourquoi c'est un composant et pas une classe (Une dll ?); mais c'est ma déformation Java
J'ai fais ça dans un TObject car comme justement je ne comptait pas trop manipuler mon objet comme un composant.

Par contre, c'est bon, ça marche, c'est Kaféine qui m'a mis la puce à l'oreil. Effectivement comme c'est un composant non visuel je n'ai pas besoin de le rattacher à une fiche et ça simplifie tout. Moi je croyais qu'un composant devait être rattaché à une fiche.

En tout cas, merci pour votre aide.

[Paul TOTH]

Hello, bienvenue dans le merveilleux monde de Delphi

Alors pour te simplifier un peu la vie voici quelques différences importants entre Delphi et Java

sous Delphi, le constructeur est virtualisable comme n'importe quelle autre méthode, et l'appel au constructeur hérité est explicite (ou n'est pas fait). S'il est invoqué cela peut se faire avant ou après dans le code. En fait l'instance objet est allouée, puis le constructeur est invoqué.

pas de garbage collector ! tout objet doit être explicitement détruit (oui ce sont des pointeurs, le constructor alloue l'instance et renvoie une pointeur sur celle ci, donc pas de "new" mais un Type.Create).

La destruction d'un objet Delphi se fait généralement par la méthode Free au lieu de Destroy. Dans le cas d'un TCustomForm il vaut mieux passer par Release qui s'assure de terminer le traitement des messages Windows avant de détruire l'objet.

TComponent détruit tous les composants dont il est propriétaire (voir Owner) quand il est détruit.

TWinControl détruit tous ses composants enfants (voir Parent) quand il est détruit.

Quand un objet est manipuler en tant qu'Interface, Delphi invoque automatiquement AddRef et Release lorsque c'est nécessaire. TInterfacedObject s'autodétruit quand on Refcount tombe à 0.

Delphi n'est pas 100% objet, on peut déclarer des procédures et des functions, des variables globales, des tableaux, des structures statiques comme en C.

La dépendance entre les unité est explicite et ne supporte pas la référence circulaire (mais on peut croiser deux unités, l'une dans l'interface et l'autre dans l'implémentation).

Voila pour commencer