Heritage TreeView + TObjectList, je pete un cableRésolu

Question

Bonjour la communauté, Je suis en train de créer une sorte de petit logiciel pour gérer un parc de machines. Dans mon logiciel pour regrouper les machines, j'utilise des groupes (c'est virtuel tout çà mais c'est pour comprendre). Chaque groupe peut etre compris dans des domaines. Domaine | |_Groupe1 - Poste1 | |_Groupe2 - Poste1 | |- Poste2 En gros j'aimerai avoir un TreeView qui contient dans la racine des domaines, dans chaque domaines des groupes, et chaque groupe contiendrai les postes. Vous aller me dire mais qu'elle est le problème. Le problème est que je veux gérer plus qu'un simple arbre, car chaque groupes et postes sont visible dans le TreeView par leur noms, mais derrière se cache une multitude d'informations comme l'IP du poste, sa MAC, un commentaire, etc... En cliquant sur un poste je doit etre capable de remonter toutes ses infos ! J'ai fait de multiple essai avec tout un tas de techniques pour finalement créer un nouvel objet hérité d'un TreeView (TElgTreeView). J'ai crée deux objets supplementaire qui sont TPoste pour gérer les postes et TGroupe pour les groupes. Ma déclaration ressemble un peu à çà : type TPoste = class( TObject ) private { Attributs } FNom : string; // Nom du poste FIP : string; // IP du poste FMAC : string; // Mac du poste FCommentaire : string; // Commentaire sur le poste FSelection : boolean; // Ligne séléctionné ou non ! public { Proprietes } property Nom : string read FNom write FNom; property IP : string read FIP write FIP; property MAC : string read FMAC write FMAC; property Commentaire : string read FCommentaire write FCommentaire; end; { -------------------------------------- GROUPE } type TGroupe = class( TObject ) private FPostes : TObjectList; // Conteneur des postes FNom : string; // Nom du groupe FCommentaire : string; // Commentaire du groupe public { Constructeur / Destructeur } constructor Create; overload; destructor Destroy; override; { Proprietes } property Nom : string read FNom write FNom; property Commentaire : string read FCommentaire write FCommentaire; { Acces a la liste des postes } property Postes : TObjectList read FPostes; { Accès aux fil } function GetPoste( Index : Integer ) : TPoste; { Metodes } procedure Ajouter ( Nom, IP, MAC, Commentaire : string ); procedure Supprimer( Index : Integer ); procedure Modifier ( Index : Integer; Nom, IP, MAC, Commentaire : string ); procedure Vider; end; { -------------------------------------- ARBRE } type TElgTreeView = class( TTreeView ) private FGroupes : TObjectList; // Conteneur des groupes public { Constructeur / Destructeur } constructor Create( AOwner: TComponent ); override; destructor Destroy; override; { Methodes } procedure Ajouter ( Nom, Commentaire : string ); procedure Supprimer ( Index : Integer ); procedure Modifier ( Index : Integer; Nom, Commentaire : string ); procedure Vider; { Rafraichissement visuel dans le TreeView } procedure Rafraichir; { Accès aux fils } property Groupes : TObjectList read FGroupes; { Sauvegarde / restauration } procedure FromFile ( const FileName : TFileName ); procedure ToFile ( const FileName : TFileName ); end; J'utilise en fait dans mon nouveau TreeView (TElgTreeView) un conteneur d'objet qui permettera de contenir les objet de type TGroupe (Groupes : TObjectList), et dans le TGroupe j'ai crée un conteneur d'objet de type TPoste (Postes : TObjectList). Ma première question est est ce que ma methode est bonne, ou plutot y à t-il (beaucoup) plus simple ? Secondo si ma methode vaut un peu quelque chose, comment gérer les "Index" des TObjectList avec les "Items" du TreeView. Sachant que les TObjectList utilise le type entier pour se positioner alors que le TreeView utilise des TTreeNode ? C'est un peu boiteux, et c'est la première fois que j'herite un composant (oh oui la honte) et que j'essai de faire un truc concret avec un TreeView (que j'utilise pratiquement jamais). Voila je sais pas si vous avez eut le courage de lire tout çà, et surtout d'avoir essayé de comprendre mais là j'pete un cable .. Merci Bcp D'avance. /\_/\ ( o.o ) ~ ElGuevel ~ > ^ <

cs_Delphiprog · Accepted Answer

Bonjour à tous ! 

Elguevel : il y a des techniques assez simples pour parvenir au résultat voulu et je t'incite à jeter un oeil sur cette page web.

Stream > Fichier INI : c'est sûr.
Si tu peux utiliser la propriété Tag d'un noeud pour distinguer s'il s'agit d'un groupe ou d'une feuille, alors les choses sont grandement simplifiées. Si, comme dans le code dont j'ai donné l'URL, tu hérites de TTreeNode, tout devient clair et limpide.


L'utilisation d'un type record avec partie variable pour enregistrer les valeurs propres à un noeud est une excellente idée.

May Delphi be with you !


<hr color="#008000" />
Pensez à cliquer sur Réponse acceptée lorsque la réponse vous convient.

Francky23012301 · Answer

Salut Damien,

Tiens la textbox évoluée fonctionne : vtie un smiley .

Alors je vais te répondre en deux parties hihi (pardon : ).

*Premièrement : autre technique.
-Mieux et beaucoup mieux : un fichier Ini.

Qd tu cliques sur un CNode ou un CNode enfant tu va chercher soit l'enfant soit le parent : hihihi. Pour récupérer l'IP et autre il te suffit de faire une recherchedans ton fichier Ini. AU pire tu peux créer plusieurs fichiers Ini : un pour l'IP, un pour le port ect ect. EN plus le fichier Ini tu peux le faire à la main donc pas besoin de coder pour la partie enregistrement des données.

Voili voilou 

*Pour ta seconde question : un CNode admet un index. Tu peux l'utiliser pour gérer les index tu TObjectList.

Regarde mon source VideoCreator : la partie treeview est copieuse . Tu vera aussi comment utiliser l'index des images pour faire le trie.

Voila 

Courage

f0xi · Answer

moi j'aurais plutot utiliser TCollectionItem et TCollection pour ça ... mais y'a tellement de moyens pour mettre en oeuvre un tel systeme que ça reviendrais a dire d'utiliser un outils avec une tranche droite pour tacer une ligne sur une feuille (une regle, une equere, un etui a cd ...).

Avantage peut etre du TCollection c'est qu'il gere facilement la gestion des items qu'on lui donne, autre avantage, il est accessible en mode conception meme si c'est pas forcement utile.
on pourrait meme juste utiliser une TList et des Record ...

La ou la solution de cirec risque de poser probleme, ce serait d'avoir trop de fichiers INI ou des fichiers INI trop lourd. sans parler de la gestion de ces derniers.
alors qu'avec les record on pourrait plus aisement les ecrire/lire dans un stream lié a la zlib et donc compressé. :)

Mais tout de meme, le TreeView ne sert que pour l'affichage des données ... donc il reste secondaire par rapport a tout cela.

<hr size="2" width="100%" />Croc (click me)

Francky23012301 · Answer

Salt f0xi,

C'était pas Cirec : lol mais merci je suis flatté.

Entierement d'accord avec toi  mais je pense qu'Elguevel a du trouver ca casse pied de faire un composant juste pour ca. Maintenant un fichier ini ca limitation est de 64Ko il me semble : tu peux en écrire avec ca ;). De plus la création des fichiers : les doigts dans le nez et meme les orteils (sauf ceux de Matt, ils sont plein de peinture).  Plusieurs fichiers ini ?? ca fait bourrain !!

Mais maintenant que tu évoques les Record : ca me semble l'une des meilleures solutions. Ce n'est pas trop compliqué et c'est bien pratique d'utilisation.

f0xi · Answer

erf, desolé pour la meprise, c'est a cause de la fatigue surrement ...

je pense que, pour n'importe quel utilisation, si on veut avoir un bon prog aussi souple en conception qu'en utilisation, faut utiliser ce qui vas le mieux, les collections ne sont peut etre pas la meilleure solution mais ça a l'avantage de donner une alternative assé puissante et pas limitée ...
et je pense que l'ecriture dans les stream est plus rapide que les fichiers ini ... mine de rien.
par contre faudrat eviter les strings ... mais plutot utiliser des string[x] mis en type pour limiter la taille.
et puis, l'ecriture d'une collection n'est pas compliquée... elle apporte meme certains avantage et limite aussi le code.
faut regarder dans mes sources, j'en ai quelques unes qui les utilises.

<hr size="2" width="100%" />Croc (click me)

Cirec · Answer

Salut,
voilà que j'écris des messages sans le savoir  
Si les symptômes persistent j'vais devoir consulter 

un peut de sérieux ... il y a une altenative à l'utilisation des String[x]  en écrivant la taille juste avant (mais cela implique l'utilisation de signet pour toutes les valeurs un peut comme l'écriture de composent dans un flux par Delphi (WriteComponent))

Sinon si tu utilises les collections tu peux te servir de 
ObjectBinaryToText
et
ObjectTextToBinary

très peut utilisées et pourtant très pratique (dans l'aide de delphi vous devriez trouver un exemple ) pour le reste vous faite marcher votre imagination et vous leurs trouverez bien une utilisation, je vous fait confiance pour cela

elguevel · Answer

Oula plein de réponse dit donc .. lol Alors déja merci pour votre attention. Francky2301201 > L'utilisation de fichier INI : Non. Je risque de gérer plusieurs centaines de machines dans ce soft et si faut créer autant de fichier INI, ou meme gérer une centaine de ligne dans un INI, je trouve çà un peu porc (et peu optimiser). De plus je ne veut pas que les utilisateurs puissent acceder au fichier directement, car s'il font des erreurs à la modification, çà va etre à moi de rajouter plein de control derrière.. enfin trop chiant. "un CNode admet un index. Tu peux l'utiliser pour gérer les index tu TObjectList." => Le problème est qu'un TreeView ne va pas avoir comme index des parent 1, 2, 3 etc mais par exemple 1, 8, 9 , 14 en fonction du nombre d'enfant qu'il a. Donc mon TObjectList lui va commencer par 0 pour allé à n. Donc il va y avoir des trous dans mon TObjectList et çà va etre imbuvable. Foxy > L'utilisation des Record, t'en fait pas j'avais commencé par la ..Avec une gestion par TList, mais çà revient à la meme chose d'avoir mes Object et ma TObjectList. Toujours le meme problème d'indexage. Sinon oui je suis tout à fait d'accord avec le fait que le TreeView ne sert qu'a l'affichage, c'est pour çà que dans ce composant je gère d'abord des objets, et au dernier moment la prodedure "Rafraichir" liste les groupe et postes pour les afficher dans le TreeView : et c'est la qu'est le probleme. Sinon je ne connais pas les TCollection, je vais allé voir çà desuite. DelphiProg > ba rien a dire pour le moment, je vais aller voir la page que tu m'a conseillé, je repond après :-) Cirec > L'enregistrement des flux, je verrai çà au dernier moment quand j'aurai déja un compo stable. Mais je pense pas que çà me pose soucis. En tout cas l'objet c'est con quand on regarde comme çà, mais là pfuu le casse tête ! Merci !!! PS : Je ne clique pas encore sur "Reponse accépté" car j'attend d'autre suggestions hihi ! /\_/\ ( o.o ) ~ ElGuevel ~ > ^ <

elguevel · Answer

Très bon DelphiProg : j'analyse tout çà car c'est ce qui correspond le mieux à mon problème pour le moment. Merci. /\_/\ ( o.o ) ~ ElGuevel ~ > ^ <

elguevel · Answer

Magnifique mon programme marche super bien .. merci. Donc pour donner un élément de réponse, et ceci de façon bcp plus simple que ce qui à été proposé, il suffisait dans le TreeView d'utiliser : Items.AddObject( ); au lieu Items.Add( ); ce qui permet de lié un objet au noeud du TreeView. exemple : Vous créez une classe avec des attributs : type TMonObjet = class( TObject ) private FNom : string; etc... end; vous crée ensuite vos node : MonTreeView.Items.AddObject( nil, LeCaption, TMonObjet .Create(Nom, etc..) ); Et vous y accedez facilement : Nom := TMonObjet ( MonTreeView.Selected.Data ).FNom; J'ai donc réussi à créer mon TreeView perso pour la gestion de Parc Info. Je le termine dès que possible et j'metterai peut etre les sources du TreeView sur DelphiFr. NB : Par contre pour l'enregistrement des données çà va être bcp plus balèse .. car il faut sauvegarder le TreeView et tous les objets associées :-s Allé, Merci Encore. /\_/\ ( o.o ) ~ ElGuevel ~ > ^ <

Arialia · Answer

Je remonte ce topic pour vous dire merci
bien que moi je développe en C# la solution est très instructive :)

Par contre vu que maintenant en ADO (j'ai vu sur la page citée par Delphiprog que vous aviez accès à ADO sous Delphi :) ), on peut avoir des Datatable virtuel , sorte de "View", je pensais faire un treeview personnalisé axé BDD relié à une "table" du genre "Type objet","id objet","nom objet","Type objet pere", "id objet pere"
donc je verrais bien une ADOTable reliée non pas à une table mais à une union des tables concernées, avec évidemment la gestion des modifications gérées par l'ADOTable ( ps je ne sais pas si ça marche pareil que sous DOTNET en Delphi , donc je vous fais de plates excuses si c'est impossible ;) )

ce qui permettrait d'avoir un treeview assez générique :)

Heritage TreeView + TObjectList, je pete un cable

10 réponses

Votre réponse

Discussions similaires