J'ai cr=E9er en m=E9moire un Array (tableau) avec 2 colonnes.
Comment puis-je retrouver si je cherche dans la 2=E9me=20
colonne un texte le N=B0 de l'index correspondant en face=20
dans la 1 =E8re colonne.
Par exemple : 2 colonnes N=B0 et jour de semaine
Je cherche mardi qui doit me retourner l'index 2 (2 =E8me=20
jour de la semaine).
J'ai vaguement essay=E9 d'utiliser la propri=E9t=E9=20
IndexedValue , mais elle ne fonctionne pas.
Donc existe-t-il dans les fonctions sp=E9cifiques des Array=20
une fonction qui permette cela (retourne l'index).
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
Michel Walsh
utilisée, pour un item donnée, ni ne vous dire si une clée donnée est déjà incluse ou non ( autrement qu'en essayant et en produisant éventuellement une erreur qu'on peut examiner). Si ces limites vous nuisent, et que vous ne désirez toujours pas utiliser de tables de base de données, alors on peut essayer les Dictionnaires (Map, en C/C++), mais leur similitude avec les collections les rend un PEU (un petit peu) dangereux, car ils se comportent comme de "faux-amis" (par comparaison entre deux langue où le même mot signifie complètement autre chose dans l'une et dans l'autre).
Pour utiliser les dictionnaires, tout d'abord inclure une référence à fso, le file scripting object, ou, officiellement, le "Microsoft Scripting Runtime" , ou encore, le fichier SYSTEMscrrun.dll, si vous préférez.
Passons au code: =================== Public Sub Dicdacdoc() Dim x As Dictionary
End Sub =================== Le début est semblable à une collection, premier faux ami, la méthode ADD demande la clé suivi de l'item. Pour un collection, la méthode ADD demande l'item, suivi de la clé. L'ordre des deux arguments est inversé.
Les dictionnaires ont une méthode Exists qui retourne vrai ou faux selon que la clé passée est déjà connue ou non. Avantage sur le collections, c'est certain. La méthode Items( ) est également la méthode par défaut. On peut donc écrire x.Items("Paris") ou simplement x("Paris"), comme pour des collections. Par contre, contrairement aux collections, utiliser une clé qui n'existe pas encore ne génère pas d'erreur, note 2. Une collection génèrerait une erreur. Mais ce qui chicotte un peu, c'est qu'utiliser une clé qui n'existe pas AUTOMATIQUE ajoute cette clé dans le dictionnaire, comme en fait foi la méthode Exists. Finallement, note 3, on peut traverser le dictionnaire, si on le désire, pour relire la clé sous laquelle est emmagaziné l'item, via la méthode Keys. En d'autres mots, pour une collection, si vous (votre code) ne connaît pas de clé, d'avance, on ne peut rien faire sortir de la collection, autrement que par
maCollection.Items( i )
mais avec un dictionnaire, vous pouvez retrouver la clé utilisée
monDico.Keys( i )
et alors, plus loin, utiliser la clé
monDico.Items( maClé )
Donc, un dictionnaire peut, à lui seul, remplacer la combinaison Tableau + Collection, car je peux y faire la recherche directe, via Keys, et la recherche inverse, via Items.
Dernier faux ami à signaler, un "for each" appliqué à un dictionnaire s'applique à la collection Keys, non à Items, comme c'est le cas pour une collection.
Dim x As Variant
For each x in monDictionnaire
équivaut à
For each x in monDictionnaire.Keys
et nous retournera les clés (chaînes de caractères, dans notre cas), non l'objet (ou la valeur, dans notre cas) emmagasiné.
La différence est encore plus importante lorsque les items emmagasinés sont des objets, plutôt que des valeurs numériques: un "for each" sur une collection retourne l'objet, mais ne retourne, par défaut, que les clés, sur un dictionnaire.
=============================== Public Sub Dicdacdoc2() Dim dico As New Dictionary Dim col As New Collection
Dim xdico As Variant Dim xcol As Variant Dim i As Long
For Each xdico In dico Debug.Print xdico Next xdico
For Each xcol In col Debug.Print xcol Next xcol
For Each xdico In dico.Items Debug.Print xdico Next xdico
End Sub
=================================
Mais tout ceci étant dit, une bonne vieille table avec un moteur de base de données, fait tout cela, et en plus, PARTAGE avec les autres utilisateurs l'information qu'elle emmagazine.
Espérant ne pas avoir été trop nébuleux, Vanderghast, Access MVP
"Steiner Ch." wrote in message news:0bc901c346c4$36a5dd80$ Bonjour,
J'ai créer en mémoire un Array (tableau) avec 2 colonnes. Comment puis-je retrouver si je cherche dans la 2éme colonne un texte le N° de l'index correspondant en face dans la 1 ère colonne.
Par exemple : 2 colonnes N° et jour de semaine Je cherche mardi qui doit me retourner l'index 2 (2 ème jour de la semaine).
J'ai vaguement essayé d'utiliser la propriété IndexedValue , mais elle ne fonctionne pas.
Donc existe-t-il dans les fonctions spécifiques des Array une fonction qui permette cela (retourne l'index).
Voilà merci pour votre aide....
utilisée, pour un item donnée, ni ne vous dire si une clée donnée est déjà incluse
ou non ( autrement qu'en essayant et en produisant éventuellement une erreur qu'on peut examiner).
Si ces limites vous nuisent, et que vous ne désirez toujours pas utiliser de tables de base de
données, alors on peut essayer les Dictionnaires (Map, en C/C++), mais leur similitude avec les
collections les rend un PEU (un petit peu) dangereux, car ils se comportent comme de "faux-amis"
(par comparaison entre deux langue où le même mot signifie complètement autre chose dans l'une et
dans l'autre).
Pour utiliser les dictionnaires, tout d'abord inclure une référence à fso, le file scripting
object, ou, officiellement, le "Microsoft Scripting Runtime" , ou encore, le fichier
SYSTEMscrrun.dll, si vous préférez.
Passons au code:
=================== Public Sub Dicdacdoc()
Dim x As Dictionary
End Sub
===================
Le début est semblable à une collection, premier faux ami, la méthode ADD demande la clé suivi de
l'item. Pour un collection, la méthode ADD demande l'item, suivi de la clé. L'ordre des deux
arguments est inversé.
Les dictionnaires ont une méthode Exists qui retourne vrai ou faux selon que la clé passée est déjà
connue ou non. Avantage sur le collections, c'est certain. La méthode Items( ) est également la
méthode par défaut. On peut donc écrire x.Items("Paris") ou simplement x("Paris"), comme pour des
collections. Par contre, contrairement aux collections, utiliser une clé qui n'existe pas encore ne
génère pas d'erreur, note 2. Une collection génèrerait une erreur. Mais ce qui chicotte un peu,
c'est qu'utiliser une clé qui n'existe pas AUTOMATIQUE ajoute cette clé dans le dictionnaire, comme
en fait foi la méthode Exists. Finallement, note 3, on peut traverser le dictionnaire, si on le
désire, pour relire la clé sous laquelle est emmagaziné l'item, via la méthode Keys. En d'autres
mots, pour une collection, si vous (votre code) ne connaît pas de clé, d'avance, on ne peut rien
faire sortir de la collection, autrement que par
maCollection.Items( i )
mais avec un dictionnaire, vous pouvez retrouver la clé utilisée
monDico.Keys( i )
et alors, plus loin, utiliser la clé
monDico.Items( maClé )
Donc, un dictionnaire peut, à lui seul, remplacer la combinaison Tableau + Collection, car je peux
y faire la recherche directe, via Keys, et la recherche inverse, via Items.
Dernier faux ami à signaler, un "for each" appliqué à un dictionnaire s'applique à la collection
Keys, non à Items, comme c'est le cas pour une collection.
Dim x As Variant
For each x in monDictionnaire
équivaut à
For each x in monDictionnaire.Keys
et nous retournera les clés (chaînes de caractères, dans notre cas), non l'objet (ou la valeur,
dans notre cas) emmagasiné.
La différence est encore plus importante lorsque les items emmagasinés sont des objets, plutôt que
des valeurs numériques: un "for each" sur une collection retourne l'objet, mais ne retourne, par
défaut, que les clés, sur un dictionnaire.
=============================== Public Sub Dicdacdoc2()
Dim dico As New Dictionary
Dim col As New Collection
Dim xdico As Variant
Dim xcol As Variant
Dim i As Long
For Each xdico In dico
Debug.Print xdico
Next xdico
For Each xcol In col
Debug.Print xcol
Next xcol
For Each xdico In dico.Items
Debug.Print xdico
Next xdico
End Sub
=================================
Mais tout ceci étant dit, une bonne vieille table avec un moteur de base de données, fait tout
cela, et en plus, PARTAGE avec les autres utilisateurs l'information qu'elle emmagazine.
Espérant ne pas avoir été trop nébuleux,
Vanderghast, Access MVP
"Steiner Ch." <christian.steiner@smart.com> wrote in message
news:0bc901c346c4$36a5dd80$a301280a@phx.gbl...
Bonjour,
J'ai créer en mémoire un Array (tableau) avec 2 colonnes.
Comment puis-je retrouver si je cherche dans la 2éme
colonne un texte le N° de l'index correspondant en face
dans la 1 ère colonne.
Par exemple : 2 colonnes N° et jour de semaine
Je cherche mardi qui doit me retourner l'index 2 (2 ème
jour de la semaine).
J'ai vaguement essayé d'utiliser la propriété
IndexedValue , mais elle ne fonctionne pas.
Donc existe-t-il dans les fonctions spécifiques des Array
une fonction qui permette cela (retourne l'index).
utilisée, pour un item donnée, ni ne vous dire si une clée donnée est déjà incluse ou non ( autrement qu'en essayant et en produisant éventuellement une erreur qu'on peut examiner). Si ces limites vous nuisent, et que vous ne désirez toujours pas utiliser de tables de base de données, alors on peut essayer les Dictionnaires (Map, en C/C++), mais leur similitude avec les collections les rend un PEU (un petit peu) dangereux, car ils se comportent comme de "faux-amis" (par comparaison entre deux langue où le même mot signifie complètement autre chose dans l'une et dans l'autre).
Pour utiliser les dictionnaires, tout d'abord inclure une référence à fso, le file scripting object, ou, officiellement, le "Microsoft Scripting Runtime" , ou encore, le fichier SYSTEMscrrun.dll, si vous préférez.
Passons au code: =================== Public Sub Dicdacdoc() Dim x As Dictionary
End Sub =================== Le début est semblable à une collection, premier faux ami, la méthode ADD demande la clé suivi de l'item. Pour un collection, la méthode ADD demande l'item, suivi de la clé. L'ordre des deux arguments est inversé.
Les dictionnaires ont une méthode Exists qui retourne vrai ou faux selon que la clé passée est déjà connue ou non. Avantage sur le collections, c'est certain. La méthode Items( ) est également la méthode par défaut. On peut donc écrire x.Items("Paris") ou simplement x("Paris"), comme pour des collections. Par contre, contrairement aux collections, utiliser une clé qui n'existe pas encore ne génère pas d'erreur, note 2. Une collection génèrerait une erreur. Mais ce qui chicotte un peu, c'est qu'utiliser une clé qui n'existe pas AUTOMATIQUE ajoute cette clé dans le dictionnaire, comme en fait foi la méthode Exists. Finallement, note 3, on peut traverser le dictionnaire, si on le désire, pour relire la clé sous laquelle est emmagaziné l'item, via la méthode Keys. En d'autres mots, pour une collection, si vous (votre code) ne connaît pas de clé, d'avance, on ne peut rien faire sortir de la collection, autrement que par
maCollection.Items( i )
mais avec un dictionnaire, vous pouvez retrouver la clé utilisée
monDico.Keys( i )
et alors, plus loin, utiliser la clé
monDico.Items( maClé )
Donc, un dictionnaire peut, à lui seul, remplacer la combinaison Tableau + Collection, car je peux y faire la recherche directe, via Keys, et la recherche inverse, via Items.
Dernier faux ami à signaler, un "for each" appliqué à un dictionnaire s'applique à la collection Keys, non à Items, comme c'est le cas pour une collection.
Dim x As Variant
For each x in monDictionnaire
équivaut à
For each x in monDictionnaire.Keys
et nous retournera les clés (chaînes de caractères, dans notre cas), non l'objet (ou la valeur, dans notre cas) emmagasiné.
La différence est encore plus importante lorsque les items emmagasinés sont des objets, plutôt que des valeurs numériques: un "for each" sur une collection retourne l'objet, mais ne retourne, par défaut, que les clés, sur un dictionnaire.
=============================== Public Sub Dicdacdoc2() Dim dico As New Dictionary Dim col As New Collection
Dim xdico As Variant Dim xcol As Variant Dim i As Long
For Each xdico In dico Debug.Print xdico Next xdico
For Each xcol In col Debug.Print xcol Next xcol
For Each xdico In dico.Items Debug.Print xdico Next xdico
End Sub
=================================
Mais tout ceci étant dit, une bonne vieille table avec un moteur de base de données, fait tout cela, et en plus, PARTAGE avec les autres utilisateurs l'information qu'elle emmagazine.
Espérant ne pas avoir été trop nébuleux, Vanderghast, Access MVP
"Steiner Ch." wrote in message news:0bc901c346c4$36a5dd80$ Bonjour,
J'ai créer en mémoire un Array (tableau) avec 2 colonnes. Comment puis-je retrouver si je cherche dans la 2éme colonne un texte le N° de l'index correspondant en face dans la 1 ère colonne.
Par exemple : 2 colonnes N° et jour de semaine Je cherche mardi qui doit me retourner l'index 2 (2 ème jour de la semaine).
J'ai vaguement essayé d'utiliser la propriété IndexedValue , mais elle ne fonctionne pas.
Donc existe-t-il dans les fonctions spécifiques des Array une fonction qui permette cela (retourne l'index).
Voilà merci pour votre aide....
Michel Walsh
Salut,
Il faut une structure autre qu'un simple espace dimentionnel de mémoire inninterrompu, tel un tableau.
Sous VB/VBA classique, ce qui serait le plus simple, après une base de données (qui en plus joue avec plusieurs utilisateurs) serait, si on est dans un monde égoïste où on ne partage pas sa "mémoire", ce serait d'utiliser un collection maintenue en parallèle avec le tableau, si on ne cherche qu'un champ (une seule colonne du tableau est à indexer). En effet, si monTableau(2) "Paris", je peux faire
Dim maCollection As Collection Set maCollection=New Collection maCollection.Add 2, "Paris"
et alors, en recherche directe, j'utilise le tableau: monTableau(2) pour trouver "Paris" et en recherche "inverse", la collection: maCollection("Paris") pour trouver 2
Les collections classiques ont quelques limitations, entre autre, elles ne peuvent pas "recracher" la clé qui fut utilisée, pour un item donnée, ni ne vous dire si une clée donnée est déjà incluse ou non ( autrement qu'en essayant et en produisant éventuellement une erreur qu'on peut examiner). Si ces limites vous nuisent, et que vous ne désirez toujours pas utiliser de tables de base de données, alors on peut essayer les Dictionnaires (Map, en C/C++), mais leur similitude avec les collections les rend un PEU (un petit peu) dangereux, car ils se comportent comme de "faux-amis" (par comparaison entre deux langue où le même mot signifie complètement autre chose dans l'une et dans l'autre).
Pour utiliser les dictionnaires, tout d'abord inclure une référence à fso, le file scripting object, ou, officiellement, le "Microsoft Scripting Runtime" , ou encore, le fichier SYSTEMscrrun.dll, si vous préférez.
Passons au code: =================== Public Sub Dicdacdoc() Dim x As Dictionary
End Sub =================== Le début est semblable à une collection, premier faux ami, la méthode ADD demande la clé suivi de l'item. Pour un collection, la méthode ADD demande l'item, suivi de la clé. L'ordre des deux arguments est inversé.
Les dictionnaires ont une méthode Exists qui retourne vrai ou faux selon que la clé passée est déjà connue ou non. Avantage sur le collections, c'est certain. La méthode Items( ) est également la méthode par défaut. On peut donc écrire x.Items("Paris") ou simplement x("Paris"), comme pour des collections. Par contre, contrairement aux collections, utiliser une clé qui n'existe pas encore ne génère pas d'erreur, note 2. Une collection génèrerait une erreur. Mais ce qui chicotte un peu, c'est qu'utiliser une clé qui n'existe pas AUTOMATIQUE ajoute cette clé dans le dictionnaire, comme en fait foi la méthode Exists. Finallement, note 3, on peut traverser le dictionnaire, si on le désire, pour relire la clé sous laquelle est emmagaziné l'item, via la méthode Keys. En d'autres mots, pour une collection, si vous (votre code) ne connaît pas de clé, d'avance, on ne peut rien faire sortir de la collection, autrement que par
maCollection.Items( i )
mais avec un dictionnaire, vous pouvez retrouver la clé utilisée
monDico.Keys( i )
et alors, plus loin, utiliser la clé
monDico.Items( maClé )
Donc, un dictionnaire peut, à lui seul, remplacer la combinaison Tableau + Collection, car je peux y faire la recherche directe, via Keys, et la recherche inverse, via Items.
Dernier faux ami à signaler, un "for each" appliqué à un dictionnaire s'applique à la collection Keys, non à Items, comme c'est le cas pour une collection.
Dim x As Variant
For each x in monDictionnaire
équivaut à
For each x in monDictionnaire.Keys
et nous retournera les clés (chaînes de caractères, dans notre cas), non l'objet (ou la valeur, dans notre cas) emmagasiné.
La différence est encore plus importante lorsque les items emmagasinés sont des objets, plutôt que des valeurs numériques: un "for each" sur une collection retourne l'objet, mais ne retourne, par défaut, que les clés, sur un dictionnaire.
=============================== Public Sub Dicdacdoc2() Dim dico As New Dictionary Dim col As New Collection
Dim xdico As Variant Dim xcol As Variant Dim i As Long
For Each xdico In dico Debug.Print xdico Next xdico
For Each xcol In col Debug.Print xcol Next xcol
For Each xdico In dico.Items Debug.Print xdico Next xdico
End Sub
=================================
Mais tout ceci étant dit, une bonne vieille table avec un moteur de base de données, fait tout cela, et en plus, PARTAGE avec les autres utilisateurs l'information qu'elle emmagazine.
Espérant ne pas avoir été trop nébuleux, Vanderghast, Access MVP
Salut,
Il faut une structure autre qu'un simple espace dimentionnel de mémoire inninterrompu, tel un
tableau.
Sous VB/VBA classique, ce qui serait le plus simple, après une base de données (qui en plus joue
avec plusieurs utilisateurs) serait, si on est dans un monde égoïste où on ne partage pas sa
"mémoire", ce serait d'utiliser un collection maintenue en parallèle avec le tableau, si on ne
cherche qu'un champ (une seule colonne du tableau est à indexer). En effet, si monTableau(2) "Paris", je peux faire
Dim maCollection As Collection
Set maCollection=New Collection
maCollection.Add 2, "Paris"
et alors, en recherche directe, j'utilise le tableau: monTableau(2) pour
trouver "Paris"
et en recherche "inverse", la collection: maCollection("Paris") pour
trouver 2
Les collections classiques ont quelques limitations, entre autre, elles ne peuvent pas "recracher"
la clé qui fut utilisée, pour un item donnée, ni ne vous dire si une clée donnée est déjà incluse
ou non ( autrement qu'en essayant et en produisant éventuellement une erreur qu'on peut examiner).
Si ces limites vous nuisent, et que vous ne désirez toujours pas utiliser de tables de base de
données, alors on peut essayer les Dictionnaires (Map, en C/C++), mais leur similitude avec les
collections les rend un PEU (un petit peu) dangereux, car ils se comportent comme de "faux-amis"
(par comparaison entre deux langue où le même mot signifie complètement autre chose dans l'une et
dans l'autre).
Pour utiliser les dictionnaires, tout d'abord inclure une référence à fso, le file scripting
object, ou, officiellement, le "Microsoft Scripting Runtime" , ou encore, le fichier
SYSTEMscrrun.dll, si vous préférez.
Passons au code:
=================== Public Sub Dicdacdoc()
Dim x As Dictionary
End Sub
===================
Le début est semblable à une collection, premier faux ami, la méthode ADD demande la clé suivi de
l'item. Pour un collection, la méthode ADD demande l'item, suivi de la clé. L'ordre des deux
arguments est inversé.
Les dictionnaires ont une méthode Exists qui retourne vrai ou faux selon que la clé passée est déjà
connue ou non. Avantage sur le collections, c'est certain. La méthode Items( ) est également la
méthode par défaut. On peut donc écrire x.Items("Paris") ou simplement x("Paris"), comme pour des
collections. Par contre, contrairement aux collections, utiliser une clé qui n'existe pas encore ne
génère pas d'erreur, note 2. Une collection génèrerait une erreur. Mais ce qui chicotte un peu,
c'est qu'utiliser une clé qui n'existe pas AUTOMATIQUE ajoute cette clé dans le dictionnaire, comme
en fait foi la méthode Exists. Finallement, note 3, on peut traverser le dictionnaire, si on le
désire, pour relire la clé sous laquelle est emmagaziné l'item, via la méthode Keys. En d'autres
mots, pour une collection, si vous (votre code) ne connaît pas de clé, d'avance, on ne peut rien
faire sortir de la collection, autrement que par
maCollection.Items( i )
mais avec un dictionnaire, vous pouvez retrouver la clé utilisée
monDico.Keys( i )
et alors, plus loin, utiliser la clé
monDico.Items( maClé )
Donc, un dictionnaire peut, à lui seul, remplacer la combinaison Tableau + Collection, car je peux
y faire la recherche directe, via Keys, et la recherche inverse, via Items.
Dernier faux ami à signaler, un "for each" appliqué à un dictionnaire s'applique à la collection
Keys, non à Items, comme c'est le cas pour une collection.
Dim x As Variant
For each x in monDictionnaire
équivaut à
For each x in monDictionnaire.Keys
et nous retournera les clés (chaînes de caractères, dans notre cas), non l'objet (ou la valeur,
dans notre cas) emmagasiné.
La différence est encore plus importante lorsque les items emmagasinés sont des objets, plutôt que
des valeurs numériques: un "for each" sur une collection retourne l'objet, mais ne retourne, par
défaut, que les clés, sur un dictionnaire.
=============================== Public Sub Dicdacdoc2()
Dim dico As New Dictionary
Dim col As New Collection
Dim xdico As Variant
Dim xcol As Variant
Dim i As Long
For Each xdico In dico
Debug.Print xdico
Next xdico
For Each xcol In col
Debug.Print xcol
Next xcol
For Each xdico In dico.Items
Debug.Print xdico
Next xdico
End Sub
=================================
Mais tout ceci étant dit, une bonne vieille table avec un moteur de base de données, fait tout
cela, et en plus, PARTAGE avec les autres utilisateurs l'information qu'elle emmagazine.
Espérant ne pas avoir été trop nébuleux,
Vanderghast, Access MVP
Il faut une structure autre qu'un simple espace dimentionnel de mémoire inninterrompu, tel un tableau.
Sous VB/VBA classique, ce qui serait le plus simple, après une base de données (qui en plus joue avec plusieurs utilisateurs) serait, si on est dans un monde égoïste où on ne partage pas sa "mémoire", ce serait d'utiliser un collection maintenue en parallèle avec le tableau, si on ne cherche qu'un champ (une seule colonne du tableau est à indexer). En effet, si monTableau(2) "Paris", je peux faire
Dim maCollection As Collection Set maCollection=New Collection maCollection.Add 2, "Paris"
et alors, en recherche directe, j'utilise le tableau: monTableau(2) pour trouver "Paris" et en recherche "inverse", la collection: maCollection("Paris") pour trouver 2
Les collections classiques ont quelques limitations, entre autre, elles ne peuvent pas "recracher" la clé qui fut utilisée, pour un item donnée, ni ne vous dire si une clée donnée est déjà incluse ou non ( autrement qu'en essayant et en produisant éventuellement une erreur qu'on peut examiner). Si ces limites vous nuisent, et que vous ne désirez toujours pas utiliser de tables de base de données, alors on peut essayer les Dictionnaires (Map, en C/C++), mais leur similitude avec les collections les rend un PEU (un petit peu) dangereux, car ils se comportent comme de "faux-amis" (par comparaison entre deux langue où le même mot signifie complètement autre chose dans l'une et dans l'autre).
Pour utiliser les dictionnaires, tout d'abord inclure une référence à fso, le file scripting object, ou, officiellement, le "Microsoft Scripting Runtime" , ou encore, le fichier SYSTEMscrrun.dll, si vous préférez.
Passons au code: =================== Public Sub Dicdacdoc() Dim x As Dictionary
End Sub =================== Le début est semblable à une collection, premier faux ami, la méthode ADD demande la clé suivi de l'item. Pour un collection, la méthode ADD demande l'item, suivi de la clé. L'ordre des deux arguments est inversé.
Les dictionnaires ont une méthode Exists qui retourne vrai ou faux selon que la clé passée est déjà connue ou non. Avantage sur le collections, c'est certain. La méthode Items( ) est également la méthode par défaut. On peut donc écrire x.Items("Paris") ou simplement x("Paris"), comme pour des collections. Par contre, contrairement aux collections, utiliser une clé qui n'existe pas encore ne génère pas d'erreur, note 2. Une collection génèrerait une erreur. Mais ce qui chicotte un peu, c'est qu'utiliser une clé qui n'existe pas AUTOMATIQUE ajoute cette clé dans le dictionnaire, comme en fait foi la méthode Exists. Finallement, note 3, on peut traverser le dictionnaire, si on le désire, pour relire la clé sous laquelle est emmagaziné l'item, via la méthode Keys. En d'autres mots, pour une collection, si vous (votre code) ne connaît pas de clé, d'avance, on ne peut rien faire sortir de la collection, autrement que par
maCollection.Items( i )
mais avec un dictionnaire, vous pouvez retrouver la clé utilisée
monDico.Keys( i )
et alors, plus loin, utiliser la clé
monDico.Items( maClé )
Donc, un dictionnaire peut, à lui seul, remplacer la combinaison Tableau + Collection, car je peux y faire la recherche directe, via Keys, et la recherche inverse, via Items.
Dernier faux ami à signaler, un "for each" appliqué à un dictionnaire s'applique à la collection Keys, non à Items, comme c'est le cas pour une collection.
Dim x As Variant
For each x in monDictionnaire
équivaut à
For each x in monDictionnaire.Keys
et nous retournera les clés (chaînes de caractères, dans notre cas), non l'objet (ou la valeur, dans notre cas) emmagasiné.
La différence est encore plus importante lorsque les items emmagasinés sont des objets, plutôt que des valeurs numériques: un "for each" sur une collection retourne l'objet, mais ne retourne, par défaut, que les clés, sur un dictionnaire.
=============================== Public Sub Dicdacdoc2() Dim dico As New Dictionary Dim col As New Collection
Dim xdico As Variant Dim xcol As Variant Dim i As Long
For Each xdico In dico Debug.Print xdico Next xdico
For Each xcol In col Debug.Print xcol Next xcol
For Each xdico In dico.Items Debug.Print xdico Next xdico
End Sub
=================================
Mais tout ceci étant dit, une bonne vieille table avec un moteur de base de données, fait tout cela, et en plus, PARTAGE avec les autres utilisateurs l'information qu'elle emmagazine.
Espérant ne pas avoir été trop nébuleux, Vanderghast, Access MVP
