Discussion :

[[ZiP]]

Bonjour,

Je développe un composant qui hérite d'un parent cependant mon composant a toutes les propriétés du parent qui s'affichent dans l'inspecteur d'objet.

Est-il possible de cacher les propriétés du parent et de n'afficher que les mienne ?

Merci,
ZiP

[J-P-B]

Salut
Malheureusement non, un dérivé ne peut pas diminuer la visibilité des membres d'une classe, il ne peut que l'augmenter.

par contre, beaucoup de composants sont développé sur la base d'une classe TCustomXXX :
Le TCustomEdit par exemple n'a que des propriétés publiques et le TEdit ne fait que dériver le TCustomEdit pour rendre publiées les propriétés publiques.
Pour faire un TEdit avec moins de prop publiées, il suffit de dériver le TCustomEdit.
Par contre, si ton composant de base n'est pas écrit comme çà, aucune solution possible

JP

[[ZiP]]

Bonjour,

Le composant que je souhaite dériver est le TWSocketServer de la suite ICS.

Je ne sais pas si il existe un TCustomWSocketServer ?

Merci,
ZiP

[J-P-B]

Je ne sais pas si il existe un TCustomWSocketServer ?

Si tu cherches la déclaration en faisant [Ctrl]+clic sur TWSocketServer, tu dois tomber sur :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
   TWSocketServer = class(TCustomWSocketServer)
    public
        property  ClientClass;
        property  ClientCount;
        property  Client;
    published
        property  Banner;
        property  BannerTooBusy;
        property  MaxClients;
        property  OnClientDisconnect;
        property  OnClientConnect;
    end;

Donc le TCustomWSocketServer existe bien et tu peux le dériver directement. Par contre, le TCustomWSocketServer possède déjà des propriétés publiées, et celles-là ne pourront pas être cachées.

JP

[Clorish]

Si ton but est de "cacher" les proprietees du parents pour avoir uen meilleur visibilitée sur le composant, c'est un peu dangereux car il doir surement faloir en affecter ou modifier certaines.

Par contre, si tu desire creer un composant "specifique" qui prends en compte certains reglages precis et rajoutant certianes fonctions, je peux te conseiller de creer uen classe independante de TWSocketServer mais qui possederais en isntance private un objet de type TWSocketServer.

Ton composant le manipulerais via tems methodes/property et peut eventuelement donner un acces en lecture seule au composant TWSocketServer interne, a moins que tu ne "Wrap" les fonctions que tu souhaite exporter.

A la limite, une version qui ne "possede" pas l'instance du socket mais dont l'instance est transmise en property peut etre interessante a envisager ...

[[ZiP]]

Bonjour,

En effet, je voudrais que mon composant est par exemple juste les propriétés suivantes :
- Host
- Port
- MaxClients

Les autres étant configurées par défaut et en arrière plan.

Quelle méthode vous semble la plus propre et profesionnelle pour réaliser celà ?

Par contre, si tu desire creer un composant "specifique" qui prends en compte certains reglages precis et rajoutant certianes fonctions, je peux te conseiller de creer uen classe independante de TWSocketServer mais qui possederais en isntance private un objet de type TWSocketServer.

Ton composant le manipulerais via tems methodes/property et peut eventuelement donner un acces en lecture seule au composant TWSocketServer interne, a moins que tu ne "Wrap" les fonctions que tu souhaite exporter.

Je dédute avec les composants, as-tu une esquisse de squelette à me proposer pour me mettre sur le bon chemin ?

Merci,
ZiP

[Clorish]

Je partirais sur la version que je t'ai proposé.

Pour moi l'interet flagrand de deriver d'une classe c'est que tout ou partie des fonctionnalitées de sa hierachie est utile.

Sinon un erivé de TComponent fera l'affaire.
Ca te permettra de pouvoir creer un composant generique, qui selon le derive que tu choisira, implemntera un TWServerSocket ou autre (Indy ?)

Chose impossible tu ne pourras pas creer d'ancetre comun aux differents types de composants serveur ...

[J-P-B]

amha, s'il s'agit de faire "framework" pour n développeurs qui devront faire n écrans, je pense que l'idée de Clorish d'intégrer le TWSocketServer en interne. A toi ensuite à développer ce qu'il faut pour traiter les propriétés cachées.
Par contre, si c'est une utilisation unique, je pense que c'est inutile ...

[Clorish]

Je dédute avec les composants, as-tu une esquisse de squelette à me proposer pour me mettre sur le bon chemin ?

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
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
Class TMonServer = Class(TComponent)
Private
  _ICSServer : TWSocketServer;
  FHost : String;
  FPort : Integer;
Public
  Constuctor Create(AOwner : TComponent); Override;
  Destructor Destroy; Override;
  Procedure Connect;
  Procedure Disconnect;
Published
  Property Host : String Read FHost Write FHost;
  Property Port : Integer Read FPort Write FPort;
End;
 
Constructor TMonServer.Create(AOwner : TComponent);
Begin
Inherited Create(AOwner);
Self._ICSServer := TWSocketServer.create(...);
End;
 
Desturctor TMonServer.Destroy;
Begin
Self._ICSServer.Free;
Inherited Destroy;
 
Procedure TMonServer.Connect;
Begin
<Connection au serveur ICS en transmettant FHost et FPort>
End;
 
Procedure TMonServer.Disconnect;
Begin
<Deconnection au serveur ICS>
End;

Etc, Etc.

[[ZiP]]

Bonjour,

C'était surtout pour l'esthétique et la simplicité d'utilisation.

Par contre, si c'est une utilisation unique, je pense que c'est inutile ...

Je pense que tu as raison. Je pense que je vais le laisser comme celà...

Merci,
ZiP

[Clorish]

Par contre, si c'est une utilisation unique, je pense que c'est inutile ...

Dans ce cas la version "compo" de la chose est elle aussi inutile "amha"

[Clorish]

Bonjour,

Une fois au debut du premier message est suffisant je pense

C'était surtout pour l'esthétique et la simplicité d'utilisation.

Moi je pense a un autre type de cas : Le jour ou tu vas changer pour X ou Y raison de composant serveur.
C'est parfoit utile d'encapsuler une classe dans une de tes classes de maniere a ce que tout changement de composant n'entraine qu'une modification de ton compo a toi et non une modification de tous les appels/types de l'application.
Si tu manipule dans ton programme une classe a toi, les appels seront toujours les memes, reste plus qu'a les "connecter" au nouveau compo.

MAis la encore ca a ses limites en fonction du niveau de l'applciation.

[[ZiP]]

En fait, je souhaite faire un IRCd à base de TWSocketServer.

Le composant gérant directement la détection des commandes et des paramètres.

Il n'y aurait plus que l'implementation de chaque commande et l'ajout de fonctionnalités éventuelles à faire pour l'utuilisateur.

Une fois au debut du premier message est suffisant je pense

C'est une mauvaise habitude que j'ai ^^

ZiP

[Clorish]

Il n'y aurait plus que l'implementation de chaque commande et l'ajout de fonctionnalités éventuelles à faire pour l'utuilisateur.

utilisateur Tiers = Diffision de la classe donc pour moi composant.
Si tu veux garder un certain controle sur ce qui se passe, je te conseille vivement d'encapsuler le TWServerSocket dans une de tes classes, ne laissant a l'utilisateur que le stricte necessaire.

1 - Ton compo en sera d'autant plus simple a manier que l'utilisateur final sera d'autant moins perdu au milieux de toutes les fonctionnalitées.

2 - Tu peux recuperer les gestionnaires d'evenements sans avoir a surcharger les methodes les applelants.

3 - Tu eviteras de truffer le code de "tests" pour eviter les erreurs de manipulations "au cas ou" l'utilisateur modifierais une property du TWServerSocket qu'il ne devrait pas modifier.

4 - Cette raison est directement lié a la precedente : ainsi d'avoir de toute maniere a surcharger et reecrire les methodes du TWSocketServer.
Effectivement si l'utilisateur modifie de port par exemple tu seras peut etre amené a devoir detecter ce changement pour maintenir uen certainte coherence aupres de certaines fonctionnalités que tu as rajouté au composant de base.

5 - Encore une fois, si tu decide pour X ou Y raison de changer de server .. ton utilisateur n'aura pas a changer son programme

6 - J'en oublie surement

[[ZiP]]

je te conseille vivement d'encapsuler le TWServerSocket

Donc de créer un composant qui n'hérite pas du TWocketServer mais qui en créé une instance cachée et l'utilise ?

Merci pour votre aide,
ZiP

[Clorish]

vala t'as tout compris

Maintenant ce n'est qu'un avis personnel, basé sur une vision assez reduite de tes besoins.

L'idee est lancée, et a toi de t'assurer qu'elle colle quand meme bien a tes besoins reels

[J-P-B]

En règle générale, je suis partisan du composant, mais il faut aussi faire gaffe à la composantonite ... sur une application unique possédant un seul composant d'accès au réseau, pour moi faire un compo sert peu:
Si on doit changer de compo, le travail devra de toute façon être fait 1 fois : soit dans composant, soit dans le projet ... et je pense amha que c'est moins agréable à faire dans un composant wrappeur ... pour une utilisation unique

Après c'est un bon exercice

[Clorish]

En règle générale, je suis partisan du composant, mais il faut aussi faire gaffe à la composantonite ... sur une application unique possédant un seul composant d'accès au réseau, pour moi faire un compo sert peu:
Si on doit changer de compo, le travail devra de toute façon être fait 1 fois : soit dans composant, soit dans le projet ... et je pense amha que c'est moins agréable à faire dans un composant wrappeur ... pour une utilisation unique

Après c'est un bon exercice

Tout a fait d'accord
Mais encore uen fois avec un bemol : Decouper son code peut etre aussi une question de lisibilité.

Je creer souvent des compos, ou simple methdoes a usage unique, pour bien structurer mon code, regroupper ce qui est commun sous un meme objet (methode) et eviter de surcharger trop certains composants/Classes/Methodes.

La lisibilité d'un code source est une chose a ne pas négliger.

Mais dans le cas present, un "wrapper" n'est pas utile, tout au mieux un derivé pour simplifier certains traitements.

[J-P-B]

La lisibilité d'un code source est une chose a ne pas négliger.

Tout à fait d'accord

[[ZiP]]

Merci pour toutes ces informations, je vais donc commencer à développer tout ça.

ZiP