Vous faites quoi avec vos fichiers de configuration?

ça fait des années que je me sers de fichiers ini pour sauver mes configurations. Le nom du fichier ini, je l'obtiens toujours de la même façon:

Code:

---

1 2	iniFileName = ChangeFileExt(Application->ExeName,".ini") ;

---

je viens de me rendre compte que ma façon de faire ne fonctionne plus sous Windows 7 si l'application est dans "Program files" (pas de droit d'écriture).

Je google donc pour trouver la façon d'obtenir des droits d'admin par prog et je tombe là-dessus:

http://stackoverflow.com/questions/9...s-of-windows-7

D'après ce que je lis, impossible d'obtenir de droit et y a en a qui remet en question la pertinence d'écrire dans program files.

Vous, vous faites quoi avec vos fichiers ini? Ou peut-être que vous les avez délaisser pour la base de registre?

Bonjour guyt,

En général, j'évite d'installer mes applications dans program files. Microsoft a prévenu depuis longtemps que ce n'était pas un répertoire comme les autres, ce qui signifie que tôt ou tard, une installation ou une mise à jour à base de copie ne fonctionnera plus.

Mais pour le cas où ce serait obligatoire, le programme contient toujours (via un fichier installé au démarrage), une liste de chemins "data" "usr" "docs", etc... En général, ces chemins sont juste des sous répertoires de mon répertoire d'installation (monprog/data, monprog/usr...), mais ils peuvent être configurés comme je veux (y compris sur un disque réseau ou distant).

L'intérêt est multiple :
- ça permet d'éviter ces problèmes Windows
- ou de mettre des données client sur un disque sauvegardé
- ou de partager des données en les mettant sur un disque serveur
- ou de tout mettre en local chez des clients dont le réseau est saturé,
- de tout faire tourner sur un support local (clef usb)

En général, j'ai presque toujours, dans mon répertoire programme, un petit fichier ini "fixe", qui me donne ces chemins, que je lis dans le constructeur de ma forme principale, avant toute chose.

A une époque, j'avais essayé les registres (c'étaient les bonnes pratiques qu'on recommandait sur l'internet). J'en suis revenu : c'est compliqué à lire et éditer (par exemple quand on a le client au téléphone et qu'on lui demande sa config), on est dans le MS-pur, donc avec le risque que les choses évoluent, et c'est la première chose qu'un admin réseau paranoiaque (c'est presque un pléonasme) bloque.

Francois

Merci Francois pour ta réponse qui fait beaucoup de sens et qui m'a convaincu de me pas y aller avec la base de registre.

Pour le répertoire de sauvegarde, il en a qui suggère l'utilisation la fonction SHGetKnownFolderPath avec "FOLDERID_Public" comme param KNOWNFOLDERID .

Ton avis éclairé là-dessus?

Merci!

Je ne sais pas trop. C'est une fonction trop récente pour que je l'utilise (la plupart de mes utilisateurs sont en XP, il en reste quelques uns en Win 2000, même...).

Mon impression, en lisant la description, c'est que la principale utilité de cette fonction est de convertir les "noms utilisateurs" des répertoires en des "vrais noms". Par exemple, elle saura que sur un Windows francophone, le répertoire "Utilisateurs" s'appelle en fait "c:\Users"

Francois

finalement, ta solution du petit fichier ini "fixe" qui contient les répertoires des autres chemins de données est celle qui je vais retenir.

merci!

Salut
je te conseille d'utiliser les fonctions mise à disposition par MS
entre autre
SHGetSpecialFolderPath
cette fonction te retourne en fonction du CSIDL le chemin complet du répertoire spécifique (Program Files..) qui diffère en fonctions des OS
cette façon de travailler te permettra d'avoir des applications compatibles avec des OS existants ou futur sans avoir à modifier des droits d'accès aux repertoires

un petit exemple d'utilisation:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

__fastcall TForm73::TForm73(TComponent* Owner) : TForm(Owner) { char lpszPath[MAX_PATH ]; if(SHGetSpecialFolderPath(this->Handle, lpszPath, CSIDL_COMMON_APPDATA, false)) Edit1->Text=lpszPath; ZeroMemory(lpszPath,MAX_PATH); if(SHGetSpecialFolderPath(this->Handle, lpszPath, CSIDL_LOCAL_APPDATA , false)) Edit2->Text=lpszPath; ZeroMemory(lpszPath,MAX_PATH); if(SHGetSpecialFolderPath(this->Handle, lpszPath, CSIDL_PROGRAM_FILES, false)) Edit3->Text=lpszPath; }

---

liste des CSIDL

CSIDL

--------------------------------------------------------------------------------

Constant special item ID list (CSIDL) values provide a unique system-independent way to identify special folders used frequently by applications, but which may not have the same name or location on any given system. For example, the system folder may be "C:\Windows" on one system and "C:\Winnt" on another. These constants are defined in Shlobj.h and Shfolder.h.

Constants

CSIDL_FLAG_CREATE (0x8000)
Version 5.0. Combine this CSIDL with any of the following CSIDLs to force the creation of the associated folder.

CSIDL_ADMINTOOLS (0x0030)
Version 5.0. The file system directory that is used to store administrative tools for an individual user. The Microsoft Management Console (MMC) will save customized consoles to this directory, and it will roam with the user.

CSIDL_ALTSTARTUP (0x001d)
The file system directory that corresponds to the user's nonlocalized Startup program group.

CSIDL_APPDATA (0x001a)
Version 4.71. The file system directory that serves as a common repository for application-specific data. A typical path is C:\Documents and Settings\username\Application Data. This CSIDL is supported by the redistributable Shfolder.dll for systems that do not have the Microsoft Internet Explorer 4.0 integrated Shell installed.

CSIDL_BITBUCKET (0x000a)
The virtual folder containing the objects in the user's Recycle Bin.

CSIDL_CDBURN_AREA (0x003b)
Version 6.0. The file system directory acting as a staging area for files waiting to be written to CD. A typical path is C:\Documents and Settings\username\Local Settings\Application Data\Microsoft\CD Burning.

CSIDL_COMMON_ADMINTOOLS (0x002f)
Version 5.0. The file system directory containing administrative tools for all users of the computer.

CSIDL_COMMON_ALTSTARTUP (0x001e)
The file system directory that corresponds to the nonlocalized Startup program group for all users. Valid only for Microsoft Windows NT systems.

CSIDL_COMMON_APPDATA (0x0023)
Version 5.0. The file system directory containing application data for all users. A typical path is C:\Documents and Settings\All Users\Application Data.

CSIDL_COMMON_DESKTOPDIRECTORY (0x0019)
The file system directory that contains files and folders that appear on the desktop for all users. A typical path is C:\Documents and Settings\All Users\Desktop. Valid only for Windows NT systems.

CSIDL_COMMON_DOCUMENTS (0x002e)
The file system directory that contains documents that are common to all users. A typical paths is C:\Documents and Settings\All Users\Documents. Valid for Windows NT systems and Microsoft Windows 95 and Windows 98 systems with Shfolder.dll installed.

CSIDL_COMMON_FAVORITES (0x001f)
The file system directory that serves as a common repository for favorite items common to all users. Valid only for Windows NT systems.

CSIDL_COMMON_MUSIC (0x0035)
Version 6.0. The file system directory that serves as a repository for music files common to all users. A typical path is C:\Documents and Settings\All Users\Documents\My Music.

CSIDL_COMMON_PICTURES (0x0036)
Version 6.0. The file system directory that serves as a repository for image files common to all users. A typical path is C:\Documents and Settings\All Users\Documents\My Pictures.

CSIDL_COMMON_PROGRAMS (0x0017)
The file system directory that contains the directories for the common program groups that appear on the Start menu for all users. A typical path is C:\Documents and Settings\All Users\Start Menu\Programs. Valid only for Windows NT systems.

CSIDL_COMMON_STARTMENU (0x0016)
The file system directory that contains the programs and folders that appear on the Start menu for all users. A typical path is C:\Documents and Settings\All Users\Start Menu. Valid only for Windows NT systems.

CSIDL_COMMON_STARTUP (0x0018)
The file system directory that contains the programs that appear in the Startup folder for all users. A typical path is C:\Documents and Settings\All Users\Start Menu\Programs\Startup. Valid only for Windows NT systems.

CSIDL_COMMON_TEMPLATES (0x002d)
The file system directory that contains the templates that are available to all users. A typical path is C:\Documents and Settings\All Users\Templates. Valid only for Windows NT systems.

CSIDL_COMMON_VIDEO (0x0037)
Version 6.0. The file system directory that serves as a repository for video files common to all users. A typical path is C:\Documents and Settings\All Users\Documents\My Videos.

CSIDL_COMPUTERSNEARME (0x003d)
The folder representing other machines in your workgroup.

CSIDL_CONNECTIONS (0x0031)
The virtual folder representing Network Connections, containing network and dial-up connections.

CSIDL_CONTROLS (0x0003)
The virtual folder containing icons for the Control Panel applications.

CSIDL_COOKIES (0x0021)
The file system directory that serves as a common repository for Internet cookies. A typical path is C:\Documents and Settings\username\Cookies.

CSIDL_DESKTOP (0x0000)
The virtual folder representing the Windows desktop, the root of the namespace.

CSIDL_DESKTOPDIRECTORY (0x0010)
The file system directory used to physically store file objects on the desktop (not to be confused with the desktop folder itself). A typical path is C:\Documents and Settings\username\Desktop.

CSIDL_DRIVES (0x0011)
The virtual folder representing My Computer, containing everything on the local computer: storage devices, printers, and Control Panel. The folder may also contain mapped network drives.

CSIDL_FAVORITES (0x0006)
The file system directory that serves as a common repository for the user's favorite items. A typical path is C:\Documents and Settings\username\Favorites.

CSIDL_FLAG_DONT_UNEXPAND (0x2000)
Combine with another CSIDL constant to ensure expanding of environment variables.

CSIDL_FLAG_DONT_VERIFY (0x4000)
Combine with another CSIDL constant, except for CSIDL_FLAG_CREATE, to return an unverified folder path—with no attempt to create or initialize the folder.

CSIDL_FONTS (0x0014)
A virtual folder containing fonts. A typical path is C:\Windows\Fonts.

CSIDL_HISTORY (0x0022)
The file system directory that serves as a common repository for Internet history items.

CSIDL_INTERNET (0x0001)
A viritual folder for Internet Explorer (icon on desktop).

CSIDL_INTERNET_CACHE (0x0020)
Version 4.72. The file system directory that serves as a common repository for temporary Internet files. A typical path is C:\Documents and Settings\username\Local Settings\Temporary Internet Files.

CSIDL_LOCAL_APPDATA (0x001c)
Version 5.0. The file system directory that serves as a data repository for local (nonroaming) applications. A typical path is C:\Documents and Settings\username\Local Settings\Application Data.

CSIDL_MYDOCUMENTS (0x000c)
Version 6.0. The virtual folder representing the My Documents desktop item.

CSIDL_MYMUSIC (0x000d)
The file system directory that serves as a common repository for music files. A typical path is C:\Documents and Settings\User\My Documents\My Music.

CSIDL_MYPICTURES (0x0027)
Version 5.0. The file system directory that serves as a common repository for image files. A typical path is C:\Documents and Settings\username\My Documents\My Pictures.

CSIDL_MYVIDEO (0x000e)
Version 6.0. The file system directory that serves as a common repository for video files. A typical path is C:\Documents and Settings\username\My Documents\My Videos.

CSIDL_NETHOOD (0x0013)
A file system directory containing the link objects that may exist in the My Network Places virtual folder. It is not the same as CSIDL_NETWORK, which represents the network namespace root. A typical path is C:\Documents and Settings\username\NetHood.

CSIDL_NETWORK (0x0012)
A virtual folder representing Network Neighborhood, the root of the network namespace hierarchy.

CSIDL_PERSONAL (0x0005)
Version 6.0. The virtual folder representing the My Documents desktop item. This is equivalent to CSIDL_MYDOCUMENTS.
Previous to Version 6.0. The file system directory used to physically store a user's common repository of documents. A typical path is C:\Documents and Settings\username\My Documents. This should be distinguished from the virtual My Documents folder in the namespace. To access that virtual folder, use SHGetFolderLocation, which returns the ITEMIDLIST for the virtual location, or refer to the technique described in Managing the File System.


CSIDL_PHOTOALBUMS (0x0045)
Windows Vista. The virtual folder used to store photo albums, typically username\My Pictures\Photo Albums.

CSIDL_PLAYLISTS (0x003f)
Windows Vista. The virtual folder used to store play albums, typically username\My Music\Playlists.

CSIDL_PRINTERS (0x0004)
The virtual folder containing installed printers.

CSIDL_PRINTHOOD (0x001b)
The file system directory that contains the link objects that can exist in the Printers virtual folder. A typical path is C:\Documents and Settings\username\PrintHood.

CSIDL_PROFILE (0x0028)
Version 5.0. The user's profile folder. A typical path is C:\Documents and Settings\username. Applications should not create files or folders at this level; they should put their data under the locations referred to by CSIDL_APPDATA or CSIDL_LOCAL_APPDATA.

CSIDL_PROGRAM_FILES (0x0026)
Version 5.0. The Program Files folder. A typical path is C:\Program Files.

CSIDL_PROGRAM_FILES_COMMON (0x002b)
Version 5.0. A folder for components that are shared across applications. A typical path is C:\Program Files\Common. Valid only for Windows NT, Windows 2000, and Windows XP systems. Not valid for Windows Millennium Edition (Windows Me).

CSIDL_PROGRAMS (0x0002)
The file system directory that contains the user's program groups (which are themselves file system directories). A typical path is C:\Documents and Settings\username\Start Menu\Programs.

CSIDL_RECENT (0x0008)
The file system directory that contains shortcuts to the user's most recently used documents. A typical path is C:\Documents and Settings\username\My Recent Documents. To create a shortcut in this folder, use SHAddToRecentDocs. In addition to creating the shortcut, this function updates the Shell's list of recent documents and adds the shortcut to the My Recent Documents submenu of the Start menu.

CSIDL_RESOURCES (0x0038)
Windows Vista. The file system directory that contains resource data. A typical path is C:\Windows\Resources.

CSIDL_SAMPLE_MUSIC (0x0040)
Windows Vista. The file system directory that contains sample music. A typical path is C:\Documents and Settings\username\My Documents\My Music\Sample Music.

CSIDL_SAMPLE_PLAYLISTS (0x0041)
Windows Vista. The file system directory that contains sample playlists. A typical path is C:\Documents and Settings\username\My Documents\My Music\Sample Playlists.

CSIDL_SAMPLE_PICTURES (0x0042)
Windows Vista. The file system directory that contains sample pictures. A typical path is C:\Documents and Settings\username\My Documents\My Pictures\Sample Pictures.

CSIDL_SAMPLE_VIDEOS (0x0043)
Windows Vista. The file system directory that contains sample videos. A typical path is C:\Documents and Settings\username\My Documents\My Videos\Sample Videos.

CSIDL_SENDTO (0x0009)
The file system directory that contains Send To menu items. A typical path is C:\Documents and Settings\username\SendTo.

CSIDL_STARTMENU (0x000b)
The file system directory containing Start menu items. A typical path is C:\Documents and Settings\username\Start Menu.

CSIDL_STARTUP (0x0007)
The file system directory that corresponds to the user's Startup program group. The system starts these programs whenever any user logs onto Windows NT or starts Windows 95. A typical path is C:\Documents and Settings\username\Start Menu\Programs\Startup.

CSIDL_SYSTEM (0x0025)
Version 5.0. The Windows System folder. A typical path is C:\Windows\System32.

CSIDL_TEMPLATES (0x0015)
The file system directory that serves as a common repository for document templates. A typical path is C:\Documents and Settings\username\Templates.

CSIDL_WINDOWS (0x0024)
Version 5.0. The Windows directory or SYSROOT. This corresponds to the %windir% or %SYSTEMROOT% environment variables. A typical path is C:\Windows.

Remarks

These values supersede the use of environment variables for this purpose.

A CSIDL is used in conjunction with one of four Shell functions, SHGetFolderLocation, SHGetFolderPath, SHGetSpecialFolderLocation, and SHGetSpecialFolderPath, to retrieve a special folder's path or pointer to an item identifier list (PIDL).

Combine CSIDL_FLAG_CREATE with any of the other CSIDLs, except for CSIDL_FLAG_DONT_VERIFY, to force the creation of the associated folder. The remaining CSIDLs correspond to either file system folders or virtual folders. Where the CSIDL identifies a file system folder, a commonly used path is given as an example. Other paths may be used. Some CSIDLs can be mapped to an equivalent %VariableName% environment variable. CSIDLs are more reliable, however, and should be used if possible.

cdlt

J'avais vu cette fonction, DjmSoftware, mais fcharton avait des réticences par rapport à la récentalité (pourquoi il est pas dans le dico, ça fait plein de sens, non?) de la fonction "SHGetKnownFolderPath".

Ce que je vais faire, c'est de vérifier si ça marche en XP dès que j'ai 10 minutes de libre.

cela fonctione depuis millenium

Citation:

---

Envoyé par DjmSoftware

cela fonctione depuis millenium

---

Faudrait que tu sois plus précis, DjmSoftware. Quand tu parles de millenium, tu parles de la version originale suédoise ou du remake américain du film?

Sérieusement, j'ai testé ton code et ça fonctionne très bien sous Windows 7 et XP, même que ça va devenir ma façon de procéder pour mes répertoires de fichiers ini.

J'ai ramené ton code en fonction générale dans ma librairie d'outils perso:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

AnsiString GetAppDataDir(HWND handle) { AnsiString stg ;   wchar_t lpszPath[MAX_PATH ]; ZeroMemory(lpszPath,MAX_PATH);   SHGetSpecialFolderPath(handle, lpszPath, CSIDL_COMMON_APPDATA,false) ; if (lpszPath[0]==NULL) SHGetSpecialFolderPath(handle, lpszPath, CSIDL_LOCAL_APPDATA, false) ; if (lpszPath[0]==NULL) SHGetSpecialFolderPath(handle, lpszPath, CSIDL_PROGRAM_FILES false) ; ; return lpszPath ;   }

---

J'en ai profité pour ajouter deux autres fonctions qui règlent une fois pour toute mon problème de localisation de fichier ini associé à l'application.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

AnsiString TGenTools::GetThisAppDataDir(HWND handle) // Retourne le chemin du répertoire de données de l'application courante, // créant au besoin le répertoire de données associé à l'application // par exemple: C:\Users\guyt\AppData\Local\ApkLoader // si le répertoire n'existe pas, il sera créer. {   AnsiString thisApp ;   thisApp = ExtractFileName(Application->ExeName) ; thisApp = ChangeFileExt(thisApp,"") ; thisApp = GetAppDataDir(handle) + "\\" + thisApp ; CreateDir(thisApp) ; // pas probleme si existait déjà return thisApp ; }   AnsiString TGenTools::GetThisAppIniFileName(HWND handle) // Retourne le chemin et nom du fichier ini associé à l'application courante // en créant au besoin le répertoire de données associé. // par exemple: C:\Users\guyt\AppData\Local\ApkLoader\ApkLoader.ini   { AnsiString iniName ;   iniName = ChangeFileExt(ExtractFileName(Application->ExeName),".ini") ; return GetThisAppDataDir(handle) + "\\" + iniName ; }

---

Un gros merci!

Salut a tous
La solution de ce poste meriterait une mise en forme et une integration dans la FAQ

Chrome Nickel
Guyt je pensais bien que tu allais abonder dans mon sens
ceci dit très bon code de ta part.
si je ne me trompe pas on pourrais encore l''ovtimiser avec un des paramètres de la fonction SHGetSpecialFolderPath (CSIDL_FLAG_CREATE (0x8000)) te permettant te créer le répertoire de ton choix aprés celui retourné par la dite fonction
mais ca je ne l'ai pas testé
cdlt

Bon, j'ai regardé plus attentivement dans msdn le flag "CSIDL_FLAG_CREATE" qui peut être combiné à un autre flag et qui force la création du répertoire. On peut obtenir le même effet en mettant "true" au paramètre "fCreate" de la fonction SHGetSpecialFolderPath, d'après ce que je crois comprendre.

Dans le cas qui nous intéresse, c'est peut-être une bonne idée de mettre ce paramètre à "true", mais c'est par principe. les deux répertoires de données des applications (commun et user) me semblent être des dossiers systèmes incontournables. En tout cas, ils ont résisté assez fortement quand j'ai essayé de les effacer!

J'ai modifié le code de la fonction "GetAppDataDir" pour qu'elle soit un peu plus flexible, en ajoutant un paramètre qui retourne le répertoire commun ou utilisateur des données des applications.

GetAppDataDir, the final cut: ;)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

AnsiString TGenTools::GetAppDataDir(HWND handle,bool userAppDir) // Retourne le point d'entrée du répertoire de données des applications // Paramètres: // handle : Handle de la forme principale // userAppDir: true (défaut) : répertoire utlisateur // ex: C:\Users\guyt\AppData\Local // false : répertoire commun // ex: C:\ProgramData // Topic: http://www.developpez.net/forums/d1206376/c-cpp // /outils-c-cpp/cppbuilder/quoi-vos-fichiers-configuration/ { AnsiString stg ; int flag ; wchar_t lpszPath[MAX_PATH];   if (userAppDir) flag = CSIDL_LOCAL_APPDATA ; else flag = CSIDL_COMMON_APPDATA ; ZeroMemory(lpszPath,MAX_PATH); if (!SHGetSpecialFolderPath(handle,lpszPath,flag,true)) lpszPath[0] = NULL ; // ça frise la paranoïa, mais bon return lpszPath ; }

---

Merci beaucoup, Guyt et Djm. Sous Win7, j'ai l'impression que ces fonctions sont moins utiles (parce que les répertoires utilisateurs ont une structure et des noms identiques pour tous les pays), mais ça va drôlement aider pour les versions antérieures.

Une question, cependant... Sous Win7 64 bits, CSIDL_PROGRAM_FILES renvoie quoi, "program files" ou "program files (x86)"?

Je dis cela parce que la coexistence des deux (et de deux versions de pas mal d'outils système) pose toutes sortes de nouveaux problèmes, qui sont certainement là pour plusieurs années (il a fallu plus de 10 ans pour éliminer le 16 bits...)

Francois

Hello
Tout naturellement
Program Files(x86)
Le répertoire program est lui réservé aux applications 64 bits
Cdlt

Citation:

---

Envoyé par blondelle

Salut a tous
La solution de ce poste meriterait une mise en forme et une integration dans la FAQ

---

C'est le cas en Delphi : Comment retrouver les répertoires spéciaux de Windows ?

Que ce soit SHGetSpecialFolderPath et SHGetSpecialFolderLocation, il est préférable d'utiliser les variantes (plus pénibles) SHGetFolderPath et SHGetFolderLocation

Sinon cela fait quelques temps, que l'on évoque la mise en quarantaine des fichiers Ini depuis l'UAC dans le répertoire VirtualStore, voir VirtualStore L'UAC et Delphi : I-A. Emplacement des données

J'avais des collègues qui double-cliquait pour ouvrir le fichier ini, pas de bol, cela n'ouvrait pas le bon, alors qu'en faisant Clic-Droit + Ouvrir avec N++, c'était le bon, que de temps perdu en maintenance !

XE ou XE2 apporte d'ailleurs de la souplesse dans la gestion de l'UAC !

Salut ShaiLeTroll

Citation:

---

XE ou XE2 apporte d'ailleurs de la souplesse dans la gestion de l'UAC !

---

Je serais très intéressé par un exemple sur la gestion de L'UAC
merci d'avance
cdlt

Il n'y a rien d'extraordinaire, c'est juste le Manifest par défaut qui a été modifié, et les prototypes des API Windows gérant l'UAC
En C++Builder, vous avez le H de MS mais en Delphi, on doit souvent les traduire soit-même en attendant la version suivante, depuis la reprise par Embarcadero, il y a eu un beau travail de couverture des headers, on avait un gros déficit en Delphi à ce sujet, mais évidemment, en C++Builder, c'est une problématique qui n'existe pas

ils ont juste intégré ce que l'on faisait manuellement comme dans le tutoriel L'UAC et Delphi via des messages avec de simple propriété

Faudrait chercher, il y a eu une vidéo sur la gestion de l'UAC justement durant un Code Way Tour, et comment différencier le VirtualStore et un dossier réel