
GETENV() - CSIDL
Utilisez getenv () pour retourner la valeur actuelle d'une variable d'environnement du
système d'exploitation.
Si dBASE ne peut pas trouver la variable d'environnement spécifiée, il retourne
une chaîne vide.
Exemples :
getEnv("computername") pour le nom de la machine
getEnv("temp") pour le chemin du répertoire temp
getEnv("path") pour les chemins de recherche
Pour lister les variables d'environnement disponibles, une bonne vieille commande Dos :
RUN SET > setListe.txt créera un fichier SetListe.txt avec le nom des variables
disponibles et leur valeur. Si vous ne spécifiez pas de chemin il sera copié dans le
répertoire que vous utilisez. Pour le lire un "modi comm setliste.txt" suffira.

un exemple des variables accessibles
Parmi les variables fréquentes : os, SystemDrive, SystemRoot, TMP, username, windir
La fonction n'est pas sensible à la casse pour la variable demandée (majuscules ou
minuscules)
à
partir des versions 32 bits : CSIDL |
Depuis les versions 32 bits, on peut obtenir plus d'informations sur les chemins des
dossiers windows en utilisant le programme de dUFLP "getWindowsCSIDLPath.prg"
qui se trouve dans MiscAPI.prg. Il est très facile à utiliser, d'où le choix de
le mentionner ici car il complète bien getenv().
CSIDL, n'est pas une instruction dBASE, par contre cela fournit des
instructions complémentaires
Précision de microsoft
:

Le système CSIDL est supporté sous Windows Vista pour des raisons de
compatibilité. Cependant, pour de nouveaux développements il faudrait utiliser des
valeurs KNOWNFOLDERID plutôt que des valeurs CSIDL
Exemple d'utilisation :
set procedure to getWindowsCSIDLPath.prg additive |
CSIDL_COMMON_APPDATA = 35 |
cFolderPath = GetWindowsCSIDLPath([cDisplayMessages],CSIDL_COMMON_APPDATA) |
? "Répertoire : " + cFolderPath |
Vous pouvez accéder ainsi aux chemins des principaux répertoires des dossiers
windows, quelque soit le nom donné par l'utilisateur.
Un exemple, des noms de répertoires que vous pouvez "récupérer" dans une
variable (sans connaître leur valeur préalablement, ici simplement en transmettant
le nombre en tête de la ligne) à l'aide de getWindowsCSIDLPath.prg :
0 C:\Documents and Settings\Administrateur\Bureau
1 //["CSIDL_INTERNET"]
Internet Explorer (icon on desktop)
2 C:\Documents and Settings\Administrateur\Menu Démarrer\Programmes
3 //["CSIDL_CONTROLS"]
My Computer\Control Panel
4 //["CSIDL_PRINTERS"]
My Computer\Printers
5 C:\Documents and Settings\Administrateur\Mes documents
6 C:\Documents and Settings\Administrateur\Favoris
7 C:\Documents and Settings\Administrateur\Menu Démarrer\Programmes\Démarrage
8 C:\Documents and Settings\Administrateur\Recent
9 C:\Documents and Settings\Administrateur\SendTo
10 //["CSIDL_BITBUCKET"]
<desktop>\Recycle Bin
11 C:\Documents and Settings\Administrateur\Menu Démarrer
12 Pour 12 pas de CSIDL,remplacé par le 5, ex ["CSIDL_MYDOCUMENTS"]
13 C:\Documents and Settings\Administrateur\Mes documents\Ma musique
14 C:\Documents and Settings\Administrateur\Mes documents\Mes vidéos
15 CSIDL inutilisé ???
16 C:\Documents and Settings\Administrateur\Bureau
17 //["CSIDL_DRIVES"]
My Computer
18 //["CSIDL_NETWORK"]
Network Neighborhood (My Network Places)
19 C:\Documents and Settings\Administrateur\Voisinage réseau
20 C:\WINDOWS\Fonts
21 C:\Documents and Settings\Administrateur\Modèles
22 C:\Documents and Settings\All Users\Menu Démarrer
23 C:\Documents and Settings\All Users\Menu Démarrer\Programmes
24 C:\Documents and Settings\All Users\Menu Démarrer\Programmes\Démarrage
25 C:\Documents and Settings\All Users\Bureau
26 C:\Documents and Settings\Administrateur\Application Data
27 C:\Documents and Settings\Administrateur\Voisinage d'impression
28 C:\Documents and Settings\Administrateur\Local Settings\Application Data
29 //["CSIDL_ALTSTARTUP"]
non localized startup
30 //["CSIDL_COMMON_ALTSTARTUP"]
non localized common startup
31 C:\Documents and Settings\All Users\Favoris
32 C:\Documents and Settings\Administrateur\Local Settings\Temporary Internet Files
33 C:\Documents and Settings\Administrateur\Cookies
34 C:\Documents and Settings\Administrateur\Local Settings\Historique
35 C:\Documents and Settings\All Users\Application Data
36 C:\WINDOWS
37 C:\WINDOWS\system32
38 C:\Program Files
39 C:\Documents and Settings\Administrateur\Mes documents\Mes images
40 C:\Documents and Settings\Administrateur
41 C:\WINDOWS\system32
42 //["CSIDL_PROGRAM_FILESX86"]
x86 C:\Program Files on RISC
43 C:\Program Files\Fichiers communs
44 //["CSIDL_PROGRAM_FILES_COMMONX86"]
x86 Program Files\Common on RISC
45 C:\Documents and Settings\All Users\Modèles
46 C:\Documents and Settings\All Users\Documents
47 C:\Documents and Settings\All Users\Menu Démarrer\Programmes\Outils d'administration
48 //["CSIDL_ADMINTOOLS"]
<user name>\Start Menu\Programs\Administrative Tools
49 //["CSIDL_CONNECTIONS"]
Network and Dial-up Connections
50 CSIDL inutilisé ???
51 CSIDL inutilisé ???
52 CSIDL inutilisé ???
53 C:\Documents and Settings\All Users\Documents\Ma musique
54 C:\Documents and Settings\All Users\Documents\Mes images
55 C:\Documents and Settings\All Users\Documents\Mes vidéos
56 //["CSIDL_RESOURCES"]
// Resource Direcotry
57 //["RESOURCES_LOCALIZED"]
// Localized Resource Direcotry
58 //["CSIDL_COMMON_OEM_LINKS"]
// Links to All Users
59 C:\Documents and Settings\Administrateur\Local Settings\Application Data\Microsoft\CD
Burning
60 CSIDL inutilisé
61 //["CSIDL_COMPUTERSNEARME"]
// Computers Near Me (computered from Workgroup membership)
Les
problèmes connus : |
La version de dUFLP
En attendant la version Z de dUFLP, téléchargez
la dernière version de getWindowsCSIDLPath.prg ici, car une précision est apportée
sur les newsgroups :
----- Original Message -----
From: "Andrew Shimmin"
Newsgroups: dbase.programming
Sent: Sunday, July 11, 2010 7:21 AM
Subject: Re: OODML and CSIDL
Il y a un bug dans la version de GetWindowsCSIDLPath() que vous avez dans dUFLP.
Après que je l'ai écrit Microsoft a remplacé CSIDL_MYDOCUMENTS avec CSIDL_PERSONAL.
J'ai joint la version avec le correctif.
There is a bug in the version of GetWindowsCSIDLPath() you have from
the dUFLP.
Somewhere after I wrote it M$ replaced CSIDL_MYDOCUMENTS with CSIDL_PERSONAL.I have
attached the version with the fix.
(Note : Ceci concerne en fait la ligne 12, dont le nom de référence a été
changé)
Remarque sur CSIDL_COMMON_DOCUMENTS
From: "O. D. Williams"
Newsgroups: dbase.programming
Sent: Tuesday, July 13, 2010 6:28 PM
Subject: Re: OODML and CSIDL (Andrew Shimmin)
Une observation sur CSIDL_COMMON_DOCUMENTS. Mon programme utilise votre routine
pour obtenir cette adresse dossier, puis l'enregistre dans un fichier INI. Avec Win XP,
l'entrée dans le fichier INI dit: C:\Documents and Settings\All Documents\Users.
Nous créons un fichier et un dossier en vertu de ce chemin. Quand nous allons à la
recherche du fichier et du dossier, il n'est pas là. En fait il n'y a pas de dossier
Documents. Au lieu de cela notre fichier se trouve dans C:\Documents and Settings\All
Users\Documents partagés.
Semble curieux qu'il l'écrive à un endroit et fait ensuite valoir qu'il est écrit dans
un autre endroit ...
La réponse :
From: "Andrew Shimmin" <shimmina@[IHateSpam]connexus.net.au>
Newsgroups: dbase.programming
Sent: Wednesday, July 14, 2010 1:42 AM
Subject: Re: OODML and CSIDL (Andrew Shimmin)
OD,
Je viens de vérifier sur mon système XPP_sp3 et j'obtiens le même résultat.
Rien ne me surprend plus avec M$.
Je n'ai pas un IDE dbplus installé sur Windows7 pour tester,
je teste des trucs sur Windows7 avec le runtime seulement.
Ce que je voudrais faire, c'est:
Ne jamais sauvegarder le chemin du dossier sous forme de chaîne après avoir appelé
getWindowsCSIDLPath().
Toujours obtenir le chemin du dossier en appelant getWindowsCSIDLPath() en ligne, soit :
if getWindowsCSIDLPath ([CSIDL_COMMON_DOCUMENTS])
f = new file(getWindowsCSIDLPath ([CSIDL_COMMON_DOCUMENTS]) + [\] +
cFileName)
else
Msgbox([BUG - le chemin CSIDL_COMMON_DOCUMENTS n'existe pas.],
programm(), 16)
endif
De cette manière vous aurez toujours le fichier dans lequel M$ le met.
L'essentiel est de regarder ces dossiers spéciaux comme CSIDL plutôt que des chemins
d'accès physiques. Si vous faites cela, le fichier sera toujours là où il est censé
être.
par exemple :
Si vous ouvrez un fichier sur XP avec:
f = new file()
f.create ([C:\Documents and Settings\All Documents\Users\nom_fichier.txt])
f.close()
Le fichier est créé dans C:\Documents and Settings\All Users\Shared Documents
Si vous utilisez:
f.create([C:\Documents and Settings\All Users\Shared Documents\nom_fichier.txt])
Windows renvoie une erreur "chemin pas trouvé", même si le dossier est
physiquement là.
arrrrgh .....
Un jour, quand j'aurai le temps, ce qui semble être jamais même quand je serais
à la retraite, je vais écrire getWindowsKnownFolderPath() pour la nouvelle version
Vista/Windows7 GUID KnownFolderPath.
Andrew
retour
Exemple réalisé avec windows XP SP 3 et dBase 2.60
Sources :
Forum dbase.programming
dUflp version V
Fichier header ShlObj.h
msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx
Si vous voyez des erreurs, n'hésitez pas à le signaler.
Dernière modification : samedi 24 juillet 2010
© M.A.
|