La documentation de Word 2002 sur la fonction Dir et son second argument ne
me semble pas claire.
Le second argument est, disons, un nombre entier traité comme champ de bits.
Voici ce que dit la documentation pour commencer :
" Dir, fonction
Renvoie une valeur de type String représentant le nom d'un fichier, d'un
répertoire ou d'un dossier correspondant à une chaîne de recherche, à un
attribut de fichier ou au nom de volume d'un lecteur.
Syntaxe
Dir[(pathname[, attributes])] "
Que faut-il entendre exactement par " correspondant à un attribut de
fichiers " ? Je crois comprendre cela comme suit : seuls seront retenus les
objets (fichiers ou dossiers) qui auront au moins les attributs impliqués
par le second paramètre, sans exclure les objets (fichiers ou dossiers) qui
auraient en plus certains autres attributs.
Exemple : la valeur vbNormal, qui est la valeur nulle, implique aucun
attribut, donc si Dir a cette valeur pour second argument, elle retiendra
tous les fichiers correspondant au premier argument, quels que soient les
systèmes d'attributs de ces fichiers.
Si on peut confirmer ou infirmer, merci d'avance.
Je vais maintenant donner un exemple de code qui me semble produire des
résultats inexplicables, quelle que soit la façon dont Dir est censée
procéder.
Avant de donner cet exemple de code et son résultat, je copie ce que la
documentation indique sur la façon de désigner les attributs :
Constante Valeur Description
vbNormal 0 (Par défaut) Spécifie les fichiers sans
attributs.
vbReadOnly 1 Spécifie les fichiers
accessibles en lecture seule ainsi que les fichiers sans attributs.
vbHidden 2 Spécifie les fichiers
cachés ainsi que les fichiers sans attributs.
vbSystem 4 Spécifie les fichiers
système ainsi que les fichiers sans attributs. Non disponible sur le
Macintosh.
vbVolume 8 Spécifie un nom de volume ;
si un autre attribut est spécifié, la constante vbVolume est ignorée. Non
disponible sur Macintosh.
vbDirectory 16 Spécifie les dossiers ainsi
que les fichiers sans attributs.
vbAlias 64 Le nom du fichier
spécifié est un alias. Disponible uniquement sur le Macintosh.
Voici maintenant un code que j'ai écrit pour tester cela :
If Dir("C:\FichierPourTesterAttributs.txt", vbNormal) <> "" Then
MsgBox "Le fichier existe déjà."
Else
MsgBox "Le fichier n'existe pas."
End If
(Remarque : la chaîne de caractères qui forme le premier argument ne finit
pas par le caractère "\". Mes essais m'ont fait conclure que, dans ce cas,
le fichier ou dossier cherché par Dir est le fichier ou dossier qui a pour
nom cette chaîne de caractères, et non un élément de ce fichier ou dossier.
L'exemple qui suit montre que c'est vrai au moins dans un cas...)
Le fichier en question dans la macro existe.
Si, avant la macro, je coche les attributs "Lecture seule" et "Archive" mais
pas l'attribut "Fichier caché", le MsgBox dit qu'il existe.
Si je coche les trois attributs "Lecture seule", "Fichier caché" et
"Archive", le MsgBox dit qu'il n'existe pas.
Je ne vois pas quelle est la règle qui peut faire attendre ce résultat.
Autres essais :
1° le fichier a pour seul attribut "lecture seule" : la macro le trouve.
2° le fichier a pour seul attribut "fichier caché" : la macro ne le trouve
pas.
Quelqu'un peut-il m'expliquer ce résultat? Merci d'avance.
Ils s'en fichent. Microsoft ne jure plus que par la plate-forme .net. Comme cela part d'une technologie complètement différente de celle qui est à la base de VB-VBA, cela équivaut à mettre VB-VBA sur une voie de garage et pratiquement d'extinction.
"Mersenne" a écrit dans le message de news:
Ça c'est vite dit. La fonction Dir() date des tous débuts de BASIC, avec MS-DOS. Sauf que depuis ce temps-là, le système d'exploitation a beaucoup évolué. Par exemple, (là c'est du vécu), un appel direct à L'API Windows dans VB6, pour, justement, lister des fichiers dans un Treeview retourne les fichiers dans le désordre avec Windows 98, alors que la même routine dans le même programme, mais dans Windows XP retourne systématiquement les fichiers en ordre alphabétique.
Avant de dire que DIR est buggué, il faudrait que cela retourne toujours la même chose avec toutes les versions de Windows. Et ça, ce n'est pas garanti.
Bonsoir Clément et tout le monde.
En tout cas, je crois que nous sommes tous d'accord pour dire que, sous Windows XP (personne n'a la possibilité d'essayer sur une autre version de Windows ?), Dir avec second argument vbNormal donne un résultat inexplicable (comparer les résultats sur un fichier ayant pour seul attribut "fichier caché" et sur un fichier ayant pour seul attribut "lecture seule").
Le problème, c'est que la documentation de Dir n'est pas très explicite.
Quelqu'un sait-il s'il est utile de signaler quelque part ce genre d'anomalies, en vue d'une future mise à jour ?
Merci d'avance.
Mersenne.
Ils s'en fichent. Microsoft ne jure plus que par la plate-forme .net. Comme
cela part d'une technologie complètement différente de celle qui est à la
base de VB-VBA, cela équivaut à mettre VB-VBA sur une voie de garage et
pratiquement d'extinction.
"Mersenne" <fa602502@skynet.be> a écrit dans le message de news:
exQz1JlMGHA.3936@TK2MSFTNGP10.phx.gbl...
Ça c'est vite dit. La fonction Dir() date des tous débuts de BASIC, avec
MS-DOS. Sauf que depuis ce temps-là, le système d'exploitation a beaucoup
évolué. Par exemple, (là c'est du vécu), un appel direct à L'API Windows
dans VB6, pour, justement, lister des fichiers dans un Treeview retourne
les fichiers dans le désordre avec Windows 98, alors que la même routine
dans le même programme, mais dans Windows XP retourne systématiquement
les fichiers en ordre alphabétique.
Avant de dire que DIR est buggué, il faudrait que cela retourne toujours
la même chose avec toutes les versions de Windows. Et ça, ce n'est pas
garanti.
Bonsoir Clément et tout le monde.
En tout cas, je crois que nous sommes tous d'accord pour dire que, sous
Windows XP (personne n'a la possibilité d'essayer sur une autre version de
Windows ?), Dir avec second argument vbNormal donne un résultat
inexplicable (comparer les résultats sur un fichier ayant pour seul
attribut "fichier caché" et sur un fichier ayant pour seul attribut
"lecture seule").
Le problème, c'est que la documentation de Dir n'est pas très explicite.
Quelqu'un sait-il s'il est utile de signaler quelque part ce genre
d'anomalies, en vue d'une future mise à jour ?
Ils s'en fichent. Microsoft ne jure plus que par la plate-forme .net. Comme cela part d'une technologie complètement différente de celle qui est à la base de VB-VBA, cela équivaut à mettre VB-VBA sur une voie de garage et pratiquement d'extinction.
"Mersenne" a écrit dans le message de news:
Ça c'est vite dit. La fonction Dir() date des tous débuts de BASIC, avec MS-DOS. Sauf que depuis ce temps-là, le système d'exploitation a beaucoup évolué. Par exemple, (là c'est du vécu), un appel direct à L'API Windows dans VB6, pour, justement, lister des fichiers dans un Treeview retourne les fichiers dans le désordre avec Windows 98, alors que la même routine dans le même programme, mais dans Windows XP retourne systématiquement les fichiers en ordre alphabétique.
Avant de dire que DIR est buggué, il faudrait que cela retourne toujours la même chose avec toutes les versions de Windows. Et ça, ce n'est pas garanti.
Bonsoir Clément et tout le monde.
En tout cas, je crois que nous sommes tous d'accord pour dire que, sous Windows XP (personne n'a la possibilité d'essayer sur une autre version de Windows ?), Dir avec second argument vbNormal donne un résultat inexplicable (comparer les résultats sur un fichier ayant pour seul attribut "fichier caché" et sur un fichier ayant pour seul attribut "lecture seule").
Le problème, c'est que la documentation de Dir n'est pas très explicite.
Quelqu'un sait-il s'il est utile de signaler quelque part ce genre d'anomalies, en vue d'une future mise à jour ?
Merci d'avance.
Mersenne.
Mersenne
Ils s'en fichent. Microsoft ne jure plus que par la plate-forme .net. Comme cela part d'une technologie complètement différente de celle qui est à la base de VB-VBA, cela équivaut à mettre VB-VBA sur une voie de garage et pratiquement d'extinction.
Ah bon ?
Et savez-vous quel est le langage qui remplacerait le VBA ?
Mersenne.
Ils s'en fichent. Microsoft ne jure plus que par la plate-forme .net.
Comme cela part d'une technologie complètement différente de celle qui est
à la base de VB-VBA, cela équivaut à mettre VB-VBA sur une voie de garage
et pratiquement d'extinction.
Ah bon ?
Et savez-vous quel est le langage qui remplacerait le VBA ?
Ils s'en fichent. Microsoft ne jure plus que par la plate-forme .net. Comme cela part d'une technologie complètement différente de celle qui est à la base de VB-VBA, cela équivaut à mettre VB-VBA sur une voie de garage et pratiquement d'extinction.
Ah bon ?
Et savez-vous quel est le langage qui remplacerait le VBA ?
Mersenne.
Clément Marcotte
Ils offrent une "extension" de VisualStudio.net qui s'appelle "VisualStudio Tools For Office".
"Mersenne" a écrit dans le message de news: e$4V$
Ils s'en fichent. Microsoft ne jure plus que par la plate-forme .net. Comme cela part d'une technologie complètement différente de celle qui est à la base de VB-VBA, cela équivaut à mettre VB-VBA sur une voie de garage et pratiquement d'extinction.
Ah bon ?
Et savez-vous quel est le langage qui remplacerait le VBA ?
Mersenne.
Ils offrent une "extension" de VisualStudio.net qui s'appelle "VisualStudio
Tools For Office".
"Mersenne" <fa602502@skynet.be> a écrit dans le message de news:
e$4V$jlMGHA.648@TK2MSFTNGP14.phx.gbl...
Ils s'en fichent. Microsoft ne jure plus que par la plate-forme .net.
Comme cela part d'une technologie complètement différente de celle qui
est à la base de VB-VBA, cela équivaut à mettre VB-VBA sur une voie de
garage et pratiquement d'extinction.
Ah bon ?
Et savez-vous quel est le langage qui remplacerait le VBA ?
Ils offrent une "extension" de VisualStudio.net qui s'appelle "VisualStudio Tools For Office".
"Mersenne" a écrit dans le message de news: e$4V$
Ils s'en fichent. Microsoft ne jure plus que par la plate-forme .net. Comme cela part d'une technologie complètement différente de celle qui est à la base de VB-VBA, cela équivaut à mettre VB-VBA sur une voie de garage et pratiquement d'extinction.
Ah bon ?
Et savez-vous quel est le langage qui remplacerait le VBA ?
Mersenne.
Mersenne
"Clément Marcotte" a écrit dans le message de news:
Ils offrent une "extension" de VisualStudio.net qui s'appelle "VisualStudio Tools For Office".
Merci de la réponse.
Je dois avouer que je ne suis pas très à la page.
"Clément Marcotte" <clement.marcotte@sympatico.ca> a écrit dans le message
de news: uPzrgulMGHA.536@TK2MSFTNGP09.phx.gbl...
Ils offrent une "extension" de VisualStudio.net qui s'appelle
"VisualStudio Tools For Office".
Ils ont déjà dit qu'ils continueraient de fournir VBA tant qu'il y aurait une demande...
"Mersenne" a écrit dans le message de news:
"Clément Marcotte" a écrit dans le message de news:
Ils offrent une "extension" de VisualStudio.net qui s'appelle "VisualStudio Tools For Office".
Merci de la réponse.
Je dois avouer que je ne suis pas très à la page.
Mersenne
Ils ont déjà dit qu'ils continueraient de fournir VBA tant qu'il y aurait une demande...
En fait, la possibilité de programmer en C# pour Office ne me semble pas une
mauvaise nouvelle. Si je suis bien informé, C# est une sorte de C++ et j'ai souvent regretté de ne pas disposer d'un langage aussi performant que le C++ ou Perl pour les macros de Word. (J'ai un peu travaillé dans ces deux langages.)
M'est avis que si OpenOffice n'imite pas Microsoft, il sera distancé...
Mersenne.
Ils ont déjà dit qu'ils continueraient de fournir VBA tant qu'il y aurait
une demande...
En fait, la possibilité de programmer en C# pour Office ne me semble pas une
mauvaise nouvelle.
Si je suis bien informé, C# est une sorte de C++ et j'ai souvent regretté de
ne pas disposer d'un langage aussi performant que le C++ ou Perl pour les
macros de Word.
(J'ai un peu travaillé dans ces deux langages.)
M'est avis que si OpenOffice n'imite pas Microsoft, il sera distancé...
Ils ont déjà dit qu'ils continueraient de fournir VBA tant qu'il y aurait une demande...
En fait, la possibilité de programmer en C# pour Office ne me semble pas une
mauvaise nouvelle. Si je suis bien informé, C# est une sorte de C++ et j'ai souvent regretté de ne pas disposer d'un langage aussi performant que le C++ ou Perl pour les macros de Word. (J'ai un peu travaillé dans ces deux langages.)
M'est avis que si OpenOffice n'imite pas Microsoft, il sera distancé...
Mersenne.
bayosky
Dans le message ,
M'est avis que si OpenOffice n'imite pas Microsoft, il sera distancé...
Ce qui serait fâcheux, OO2 commence à peine à avoir ce qu'office possède depuis très logtemps : des objets ( formulaires, etc...) parfaitement contrôlables :o)
HB
Dans le message uUy2ButMGHA.2040@TK2MSFTNGP14.phx.gbl,
M'est avis que si OpenOffice n'imite pas Microsoft, il sera
distancé...
Ce qui serait fâcheux,
OO2 commence à peine à avoir
ce qu'office possède depuis très logtemps :
des objets ( formulaires, etc...) parfaitement contrôlables :o)
M'est avis que si OpenOffice n'imite pas Microsoft, il sera distancé...
Ce qui serait fâcheux, OO2 commence à peine à avoir ce qu'office possède depuis très logtemps : des objets ( formulaires, etc...) parfaitement contrôlables :o)
