Discussion :

[siro1]

Bonjour, je suis acctuellement en train de travailler sur un projet en Winform et j'aimerai utiliser les fichiers ini pour pouvoir sauvegarder ma configuration d'application. Par exemple, si lors de l'utilisation de mon applcation je modifie manuellement la largeur ou position d'une fentre, j'aimerai que ce parametre soit enregistrer de façon à ce que la prochaine fois , lorsque j'ouvrirai cette fenetre , elle soit à la meme position que quand je l'avait ferner. Et ce pour tout autres types de composants tel que les datagrid(longeur, largeur, position des collones . . .)

Quelqu'un aurait-il une methode, simple est efficace ?

Merci

[Médinoc]

Les fichiers ini ont tendance à être passés de mode.
De nos jours, soit on utilise le Registre, soit la configuration XML de .Net (encore peu usitée).

Sinon, je ne sais plus à quoi servent exactement les Settings de Windows Forms, mais ça peut être lié aux histoires de configuration XML. À voir.

[bacelar]

.INI, c'est une vieille méthode qui ne permet pas de faire une distinction entre les configurations au niveau application et celles au niveau de l'utilisateur.
Sommes-nous d'accord que votre sauvegarde est liée à un utilisateur et pas à toute l’application?

Voici un tutoriel pour utiliser les fichiers de configuration .NET en C++/CLI.
http://nico-pyright.developpez.com/t...rationsection/

[Mac LAK]

Pas en base de registre, svp : ça pollue et c'est une utilisation abusive du mécanisme... Surtout que je ne connais pas beaucoup de développeurs qui ont la courtoisie de nettoyer la BDR des scories faites après l'installation lors de la désinstallation du programme.
Au moins, un .INI, ça se nettoie sans chercher trop fort, c'est un des fichiers qui reste après la désinstallation et qui fait gueuler le setup comme quoi il n'a pas pu supprimer le répertoire de l'application.

Le .INI, situé dans le répertoire de l'application elle-même, est la solution la plus simple (cf. WritePrivateProfileString et fonctions associées). Toutefois, comme toute fonctionnalité simple, elle a des inconvénients : notamment, rien ne sera sauvegardé (ni relu !!!) si tu ne le décides pas toi-même.
Sauvegarder la position de la fenêtre ? Quatre valeurs à sauver... La position des splitters ? Encore une valeur... Le dernier chemin d'ouverture de fichier ? Et une chaîne, une ! Etc.

L'autre méthode, c'est le XML : plus lourd à manipuler qu'un .INI, certes, mais derrière, tu as une structure en RAM pouvant être lue et écrite, et surtout, re-sérialisée sur le disque. De plus, en fonction de la technologie / plate-forme, les objets graphiques savent parfois s'initialiser depuis un flux XML, et également se "sauver" dedans. Avec des plate-formes un peu évoluées (.NET, ou encore des RAD comme BCB/Delphi), c'est une méthode plus souple et fiable que le .INI "classique". Par contre, ça demande du boulot pour se mettre le mécanisme dans la tête.

.INI, c'est une vieille méthode qui ne permet pas de faire une distinction entre les configurations au niveau application et celles au niveau de l'utilisateur.

Et les sections, ça sert à quoi d'après toi ??

[bacelar]

Et les sections, ça sert à quoi d'après toi ??

En section par utilisateur ??
Et avec un utilisateur qu'on ne connait ni d'eve ni des dents ?

[Médinoc]

Et les sections, ça sert à quoi d'après toi ??

Ce n'est pas une section qui va te permettre de modifier ton fichier ini dans Program Files en tant qu'utilisateur limité...

[Mac LAK]

En section par utilisateur ??
Et avec un utilisateur qu'on ne connait ni d'eve ni des dents ?

Sûr, c'est très difficile de récupérer le nom de l'utilisateur courant depuis le thread principal, et d'utiliser cet identifiant soit comme préfixe de nom de section, soit de générer un .INI spécifique pour cet utilisateur... Marche aussi avec un XML, d'ailleurs, ça permet de pouvoir supprimer une personnalisation sans devoir perdre les autres ou éditer manuellement le XML.

Après, faut aussi faire attention à ce que l'on stocke dans un fichier de configuration lisible (inclus XML, donc), genre mots de passe en clair et autres informations personnelles.
Il faut aussi relativiser la paranoïa : là, on parle d'une application end-user, où l'on doit "protéger" des données de configuration de façon toute relative, vu que l'on doit juste éviter de mélanger les préférences des personnes qui ont un accès physique à la machine, c'est à dire la propre famille de l'utilisateur...

Ce n'est pas une section qui va te permettre de modifier ton fichier ini dans Program Files en tant qu'utilisateur limité...

Bof... Un coup de GetVersionEx, puis tu prends FOLDERID_ProgramData sous Vista (%APPDATA% en variable d'environnement) si tu veux éviter ce souci. Si cela pouvait être le seul et unique problème lors d'un développement, on serait chez les Bisounours...

[bacelar]

Le truc, c'est qu'avec C++/CLI et des fichiers de configurations en XML, toutes ces cochonneries à faire à la main, et bien d'autre, sont faites de manières TOTALEMENT transparentes.