Treeview : récupérer le chemin complet d'un noeud

Soyez le premier à donner votre avis sur cette source.

Vue 12 140 fois - Téléchargée 758 fois

Télécharger le projet
Commenter

Description

Le chemin complet d'un noeud "x" peut être récupérer via "x.FullPath". Cette méthode énumère en interne chaque père de "x". Or, si "y" a le même père que "x", il est inutile de remonter jusqu'à la racine de l'arbre... Pour combler cette lacune, je propose ici une autre méthode (TVWGetFullPath) qui tire avantage des précédents appels.

Source / Exemple : 


'**************************************************************************************
' .FullPath vs GetFullPath
'
'Programmeur :             Egyde (sendoval_fr@yahoo.fr)
'Date de création :        22/02/06
'**************************************************************************************
Option Explicit

Private m_strParentPath As String
Private m_strParentKey  As String

'pr l'estimation des performances
Public Declare Function GetTickCount Lib "kernel32" () As Long

'pr récupérer le chemin complet d'un noeud,
'on fait appel à la propriété .FullPath
'Note : pour changer le séparateur (ici "/"), voir .PathSeparator du treeview
Public Function TVWFullPath(ByRef tSourceNode As Node) As String
    TVWFullPath = tSourceNode.FullPath
    TVWFullPath = Mid$(TVWFullPath, 2, Len(TVWFullPath) - 1) & "/"
End Function

'pr récupérer le chemin complet d'un noeud,
'on check si le noeud visité n'est pas le fils du père précédemment visité.
'Si c'est le cas, on renvoi le chemin complet en tenant compte de l'information
'précédemment sauvegardée. Si c'est pas le cas, on fait appel à la propriété
'.FullPath
Public Function TVWGetFullPath(ByRef tSourceNode As Node) As String
        
    If tSourceNode.Parent Is Nothing Then ' on est à la racine
        
        m_strParentKey = "K0"
        m_strParentPath = "/"
        TVWGetFullPath = "/"
    
    Else

        If m_strParentKey <> tSourceNode.Parent.Key Then
            'le noeud courant n'est pas au même niveau que le noeud précédent
            'on met donc à jour le chemin du père
            m_strParentKey = tSourceNode.Parent.Key
            m_strParentPath = TVWFullPath(tSourceNode.Parent)
        End If
    
        'on concatène au chemin du père le texte du fils
        TVWGetFullPath = m_strParentPath & tSourceNode.Text & "/"

    End If
    
End Function

Conclusion :


Lorsque l'arbre doit être visité de façon récursive (comme c'est le cas pour un explorateur automatique par exemple), la stratégie proposée est plus efficace qu'un appel naif à .FullPath (moyenne obtenue pour 9331 noeuds - voir projet joint) :

TVWFullPath : 0.60615 tick (par noeud, en moyenne)
TVWGetFullPath : 0.56093 tick

Toutefois, dans le cas d'un parcours "aléatoire" (ex : un utilisateur qui clic sur un noeud quelconque), .FullPath est, comme on pourrait s'y attendre, plus efficace en moyenne :

TVWFullPath : 0.81224 tick (par noeud, en moyenne)
TVWGetFullPath : 0.84225 tick

Un bon compromis consiste donc à utiliser .FullPath pour récupérer le chemin de noeuds qui n'ont a priori aucun lien de parenté et TVWGetFullPath lorsque la récupération du chemin se fait de façon récursive.
Télécharger le projet

Codes Sources

A voir également

Ajouter un commentaire

Commentaires

Signaler
cs_EBArtSoft
Messages postés
4531
Date d'inscription
dimanche 29 septembre 2002
Statut
Modérateur
Dernière intervention
22 avril 2019
 5 -
Comme dirait l'autre beaucoup de code pour pas grand chose
Signaler
Egyde
Messages postés
161
Date d'inscription
lundi 17 mai 2004
Statut
Membre
Dernière intervention
16 juillet 2007
 -
Si tu trouves que 10 lignes de codes, ça fait beaucoup, je peux rien faire pour toi, dsl. Pour ce qui est des performances, un gain de 0.1ms par appel c'est certe peu mais en même temps, si tu sais faire mieux en VB, ça m'interesse... Mieux avec 9 lignes de codes peut-être?
Signaler
cs_EBArtSoft
Messages postés
4531
Date d'inscription
dimanche 29 septembre 2002
Statut
Modérateur
Dernière intervention
22 avril 2019
 5 -
Egyde>Ahah ne me lance sur ce terrain je pourais te surprendre !
Ce que j'essaie de te dire c'est que ton travail est certe interressant d'un point de vue "artistique" mais qu'il na pas vraiment de sens.

Car on optimise pas un code comme celui la. Quel est l'avantage d'avoir le chemin complet d'un noeud en 0.81224 tick contre 0.84225 ??? Deja si j'ai besoin du chemin complet dans un code critique je me fait mon propre tableau ce qui m'evitera d'appeler des propriete qui sont 15 fois plus gourmande. Et quel est le programmeur qui va ecrire un code critique sur un treeview ???

Bref je prends mon FullPath en 1 ligne et gagne beaucoup plus de temps que de tout recoder dans le pire des cas je fais une premiere passe et je fout mon fullpath dans la prp .tag et la ..... oh bonheur lol

Avant de coder dans tout les sens je me demande toujours si le jeu en vaux la chandelle. Surtout que la recursivité n'a pas que du bon !

@+
Signaler
Egyde
Messages postés
161
Date d'inscription
lundi 17 mai 2004
Statut
Membre
Dernière intervention
16 juillet 2007
 -
Si tu travailles avec des arbres qui font plusieurs dizaines de milliers de noeuds (comme je le fais), c'est pas tout à fait dénué de sens... D'autant que si tu avais réfléchis un petit plus à la question avant de me critiquer, tu aurais compris que le gain est proportionnel au nombre de fils par branches (Je code actuellement un explorateur FTP : dans le cas "concret" de pub 21 avec de nombreux mazes, ce code m'a déjà permis de réduire d'une 30aine de secondes l'exploration).

Quand à mettre le fullpath dans la propriété .tag, c'est une bonne idée :) Encore faut-il être prêt à gaspiller l'espace mémoire pour ça ;)
Signaler
Egyde
Messages postés
161
Date d'inscription
lundi 17 mai 2004
Statut
Membre
Dernière intervention
16 juillet 2007
 -
Juste pour préciser que dans l'exemple cité (explorateur FTP), .tag n'est PAS une idée : une fois le path obtenu et les commandes CWD+LIST+etc envoyées, fullpath n'est plus requis donc string en mémoire pour quedale... Et je parle pas de la redondance dans tes chaînes.

Tu as une autre idée? Je pensais à un retour ByRef plutôt qu'une fonction As String mais j'ai pas réussi à mettre en évidence de différences.
S'inscrire maintenant

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.

Du même auteur (Egyde)