Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Visual Basic Key dans la collection node d'un treeview

Key dans la collection node d'un treeview

8 réponses
Avatar
Patrice Ongla
Bonsoir à tous,

Il n'y a plus de clé (Key) dans la collection de nodes des treeview ?
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
A
Salut,
Tu peux utiliser la propriété tag, cela peut te permettre de combler
l'absence de la Key.

Sébastien

"Patrice Ongla" a écrit dans le message de news:
4208f793$0$488$
Bonsoir à tous,

Il n'y a plus de clé (Key) dans la collection de nodes des treeview ?



Avatar
Patrice Ongla
Merci mais non, pas pour accéder aux nodes aléatoirement et c'est quand mm
le plus important (dans mon cas en tout cas). Je trouve incroyable ce genre
de régression. On le disait déjà de la 1.0 mais en l'état, je trouve que la
plateforme 1.1 n'est pas finie, ou en tout cas insuffisante (cf. mon post en
réponse à Pierre Alexis, "Nested class and scope" --> "DotNet pas mûr ? ").
En 2.0, la key est revenue. Vivement la sortie officielle.


"A" a écrit dans le message de news:
cuch5l$5gr$
Salut,
Tu peux utiliser la propriété tag, cela peut te permettre de combler
l'absence de la Key.

Sébastien

"Patrice Ongla" a écrit dans le message de news:
4208f793$0$488$
Bonsoir à tous,

Il n'y a plus de clé (Key) dans la collection de nodes des treeview ?







Avatar
Zoury
Salut Patrice !

Que cherches-tu à faire ? Nous pourrons peut-être te trouver une solution en
attendant la 2.0.

--
Cordialement
Yanick
MVP pour Visual Basic
"Patrice Ongla" a écrit dans le message de
news:420a9488$0$501$
Merci mais non, pas pour accéder aux nodes aléatoirement et c'est quand mm
le plus important (dans mon cas en tout cas). Je trouve incroyable ce


genre
de régression. On le disait déjà de la 1.0 mais en l'état, je trouve que


la
plateforme 1.1 n'est pas finie, ou en tout cas insuffisante (cf. mon post


en
réponse à Pierre Alexis, "Nested class and scope" --> "DotNet pas mûr ?


").
En 2.0, la key est revenue. Vivement la sortie officielle.


"A" a écrit dans le message de news:
cuch5l$5gr$
> Salut,
> Tu peux utiliser la propriété tag, cela peut te permettre de combler
> l'absence de la Key.
>
> Sébastien
>
> "Patrice Ongla" a écrit dans le message de news:
> 4208f793$0$488$
>> Bonsoir à tous,
>>
>> Il n'y a plus de clé (Key) dans la collection de nodes des treeview ?
>>
>
>




Avatar
Patrice Ongla
Merci d'avance. Je veux simplement être capable :
1) de savoir si un élément est ou non déjà dans l'arbre
2) d'y accéder et de le sélectionner.

Bien sûr, y'a la solution de la boucle avec une clé stockée dans le tag mais
dans un cas, la recherche serait imbriquée dans une autre boucle, et si
l'arbre est gros, ça va finir par coûter cher en temps d'exécution .
J'ai bien une solution de bricolage avec un hash table stocké à côté. Mais
outre que c'est très laid, on paye en mémoire ce qu'on gagne en temps. Bon
c'est vrai que de nos jours...
S'il y a mieux (et économique ! je ne tiens pas à implémenter idictionnary
en sous-classant le treenode et le treeview) je suis bien volontier preneur.
Mais c'est pas si terrible en soi et j'ai de toutes façons une solution. Non
ce qui me tracasse c'est le fait même de ce genre de lacune. C'est un
exemple mais il y en a d'autres (j'énumère ?). Je ne voudrais surtout pas
jouer les troll (d'autant que je continue de penser que .net est globalement
un joli truc) mais pour l'heure, je suis drastiquement moins productif en
.net qu'en VB6. A des années lumière du discours marketing. Je veux encore
croire que c'est le ticket d'entrée .net qui est cher et qu'on regagne
ensuite au centuple. Mais j'avoue que je commence à en douter. Peut-être
qu'avec la 2.0... J'en suis à réenvisager java pour mon projet (et pourtant
je ne suis pas fan).
Je serais curieux des avis de la communauté.

Cdt,

"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de
news:
Salut Patrice !

Que cherches-tu à faire ? Nous pourrons peut-être te trouver une solution
en
attendant la 2.0.

--
Cordialement
Yanick
MVP pour Visual Basic
"Patrice Ongla" a écrit dans le message de
news:420a9488$0$501$
Merci mais non, pas pour accéder aux nodes aléatoirement et c'est quand
mm
le plus important (dans mon cas en tout cas). Je trouve incroyable ce


genre
de régression. On le disait déjà de la 1.0 mais en l'état, je trouve que


la
plateforme 1.1 n'est pas finie, ou en tout cas insuffisante (cf. mon post


en
réponse à Pierre Alexis, "Nested class and scope" --> "DotNet pas mûr ?


").
En 2.0, la key est revenue. Vivement la sortie officielle.


"A" a écrit dans le message de news:
cuch5l$5gr$
> Salut,
> Tu peux utiliser la propriété tag, cela peut te permettre de combler
> l'absence de la Key.
>
> Sébastien
>
> "Patrice Ongla" a écrit dans le message de news:
> 4208f793$0$488$
>> Bonsoir à tous,
>>
>> Il n'y a plus de clé (Key) dans la collection de nodes des treeview ?
>>
>
>








Avatar
Zoury
Salut Patrice!

Merci d'avance. Je veux simplement être capable :
1) de savoir si un élément est ou non déjà dans l'arbre
2) d'y accéder et de le sélectionner.


<snip>
J'ai bien une solution de bricolage avec un hash table stocké à côté. Mais
outre que c'est très laid,



Tu peux faire une classe hérité du TreeView et y stockée ta Hashtable
dedans.. tu peux ainsi ajouter un méthode (ex: GetNodeFromKey) ce qui
rendrait le concept totalement transparent.


on paye en mémoire ce qu'on gagne en temps. Bon
c'est vrai que de nos jours...



Seul la référence vers le noeud sera conserver dans la hashtable soit 4
octets (taille du pointeur), plus la taille de la clé... le sacrifice est
assez minime pour le temps d'éxécution que tu sauveras.



Je serais curieux des avis de la communauté.



et bien voici la mienne.. C'est bien vrai qu'il manque encore quelques
petites choses que rendrait le Framework généralement plus plaisant. Je
m'estime toutefois très sastisfait de ce qu'on peut y accomplir pour
l'instant. La librarie de classe est quand même volumineuse si on compare
aux quelques fonctions/méthodes que nous offraient VB 6.

--
Cordialement
Yanick
MVP pour Visual Basic
Avatar
Patrice Ongla
Bonjour Yannick

Tu peux faire une classe hérité du TreeView et y stockée ta Hashtable
dedans.. tu peux ainsi ajouter un méthode (ex: GetNodeFromKey) ce qui
rendrait le concept totalement transparent.



Exact, c'est mieux et ça devient à peu près propre pour pas trop cher.
J'achète.

on paye en mémoire ce qu'on gagne en temps. Bon
c'est vrai que de nos jours...



Seul la référence vers le noeud sera conserver dans la hashtable soit 4
octets (taille du pointeur), plus la taille de la clé... le sacrifice est
assez minime pour le temps d'éxécution que tu sauveras.



Exact.

Merci :)
Avatar
Patrice Ongla
>> Je serais curieux des avis de la communauté.



et bien voici la mienne.. C'est bien vrai qu'il manque encore quelques
petites choses que rendrait le Framework généralement plus plaisant. Je
m'estime toutefois très sastisfait de ce qu'on peut y accomplir pour
l'instant. La librarie de classe est quand même volumineuse si on compare
aux quelques fonctions/méthodes que nous offraient VB 6.



C'est un peu le pb justement. Je précise pour éviter les ambiguïté que je
suis convaincu de la puissance de framework. C'est même la 1ère raison pour
laquelle j'ai choisi cette outil pour mon projet. La 2e c'était la
simplicité et l'intuitivité. Et là... La puissance c'est bien mais dans 90%
des cas, on fait des choses très simples. 90% des projets sont triviaux, et
90% des lignes de codes d'un projet complexe sont basiques. Donc je crois
que le plus important ce n'est pas la puissance mais la simplicité
(intuitivité, lisibilité, etc...) pour peu qu'on ait des solutions
alternatives.C'était le cas avec VB6. Pour le simple j'avais VB6. Le
champion du monde undisputed de la lisibilité. Quand ça devenait plus
compliqué (ce qui reste globalement l'exception) j'avais les API. Je n'ai
JAMAIS été bloqué avec cette solution (j'ai pourtant fait des trucs un peu
bas niveau et un peu système). Simplement, je ne me coltinais la difficulté
QUE lorsque j'en avais EFFECTIVEMENT besoin. Et là c'est vrai, la difficulté
était plus grande qu'avec le framework mais au moins, je savais pkoi je
suais. Là, ce qui m'horripile c'est de devoir se poser des questions et se
gratter la tête souvent pour faire des choses basiques (mais je suis peut
être le seul dans ce cas, j'aimerais savoir). Cest effectivement ce type de
doléances qui est à l'origine je crois, de l'apparition de "my" dans VS2005.
Et à côté de cette débauche de puisssance qu'est le framework, on manque de
certaines fonctionnalités élémentaires. Je prends qq exemples et je précise
que je peux me tromper, je débute sous .net. Mais le fait même que je me
gourre montrerait que la bonne solution ne saute pas au yeux (ou que je suis
une bille, c'est possible aussi :), ce qui est un pb en soi (j'ai choisi
cette solution pour aller vite !)
Je prends qques exemples (corrigez moi qd je me trompe):

1 - L'accès aux données : d'un côté j'ai une techno dataset super riche et
de l'autre :
- Les relations entre les tables ne sont pas automatiquement récupérées
de la base (PK, FK). Il faut toutes les créer à la main. C'est très long.
- Les relations ne sont pas typées. J'ai une belle techno dataset typée
et les relations ne sont pas typée. Si je me gourre dans le nom d'une
relation sur un get_parent_rows (que j'ai du resaisir à la main je le
rappelle), je m'en rend compte qu'à l'exécution.Et encore, je n'ai même pas
d'erreur d'exécution, juste une erreur de la logique applicative, je peux ne
pas l'en rendre compte du tout ! Quitte à générer du code typé pourquoi
avoir d'un côté un beau type VendeurDataTable et de l'autre ne pas pour
faire MonVendeur.Ventes plutôt que MonVendeur.GetChildRows("Ventes") ?
- Des comportements étonnants.
--> Cf mon post "DefaultView et mise à jour de DataGrid et
databinding" du 09/02. C'est typiquement le genre de truc incompréhensible à
priori pour moi (je n'AI PAS et je NE VEUX PAS rentrer dans le
focntionnement interne des grid et des textbox pour comprendre, je n'ai pas
le temps)
- Impossible de filter uen datable d'un dataset pour son affichage dans
un form via des contrôles bindés (on ne peut que rendre un tableau de row).
Donc, après un bon moment, je finis par comprendre (je crois) qu'il faut
préférer binder sur des vues. Résultat : pour l'heure je n'arrive pas à
mettre à jour (aucun changement détectés dans le dataset sous-jacent).
Insupportable.
- Les vues ne sont pas typées. Si je travaille sur les vues, je perds
l'avantage du typage. En gros, tout àa mis bout à bout, pour moi ça fiche
par terre, l'intérêt des dataset typés. Dommage quand même...
- Le pire (pour moi). Pas de mapping O/R. Je sais, ça y travaille. Mais
quand on sort une plateforme qui met à ce point en avant l'orientation
objet, je trouve ça limite. En tout cas, moi ça me coûte du temps (et les
bon outils tiers sont chers). Enfin je sais que c'est pas un sujet simple...

2 - Un langage très verbeux. C'est lié à la richesse fonctionnelle mais voir
ma 1ère remarque sur le sujet. C'est poluant dans la pluspart des cas
puisque dans la plupart des cas on fait simple. Résultat, il faut wrapper
soit même les fonctionnalité riches/complexes pour ne pas se trimballer
systématiquement un tank pour écraser une mouche. C'est ce que fait par
exemple le Data Access Block. Donc à mon avis MS en est conscient.

Voir mon post "Re: Objet performance drawing.image." du 17/01 : VB6 : 7
lignes, 133 carcatères / VB.Net : 8 l, 296 c. Dans cet exemple, le pire
c'est que c'est même pas VB.Net Vs VB6, c'est VB.Net Vs VB6 + API Win32 !
Vainqueur lisibilité, concision : VB6.

ou encore (trouvé sur un ng) :
------------------------
Whereas in VB6 you might see.
TreeView1.Nodes.Add 1, 1, "Key", "text", 2, 3

the equivalent in VB.Net might be.
Dim oNode As New System.Windows.Form.TreeNode
oNode.Text = "Text"
oNode.ImageIndex = 2
oNode.SelectedImageIndex = 3
TreeView1.nodes.add oNode
------------------------

3 - Pleins de petites autres choses (souvent de petites régressions, l'aide
en ligne insuffisante voir indigente dans certains cas, pas de Nested child
en XML, etc...) que je veux bien mettre sur le compte de défauts de jeunesse
mais qd mm énervantes parceque demandant toujours un petit effort
supplémentaire. En gros, on passe 5 ou 10 mn là où on pensait en passer 1
(exemple Key sur le treenode). Multiplier par X sur un projet....

Je serais ravi qu'on m'explique que je me gourre sur la plupart des points.
Avis à tous.
Avatar
Patrice Ongla
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de
news:
Salut Patrice!

Merci d'avance. Je veux simplement être capable :
1) de savoir si un élément est ou non déjà dans l'arbre
2) d'y accéder et de le sélectionner.


<snip>
J'ai bien une solution de bricolage avec un hash table stocké à côté.
Mais
outre que c'est très laid,



Tu peux faire une classe hérité du TreeView et y stockée ta Hashtable
dedans.. tu peux ainsi ajouter un méthode (ex: GetNodeFromKey) ce qui
rendrait le concept totalement transparent.



Agacement. Le principe de la solution est bonne mais.... Pas d'event
node_added sur un treeview ! Résultat, il faut que je dérive encore
treenodecollection. Bien sûr c'est trivial mais si je travaille avec le
framework de microsoft, c'est bien pour me concentrer sur MON pb et pas pour
réécrire des contrôles de base. Je crois qu'il est cencé être pensé pour ça
non ? Ca commence à faire beaucoup de boulot pour un truc qui n'en demandait
ABSOLUMENT AUCUN. C'est quand même un peu souvent comme ça...