Fichier .ini et Winform en C++

Version imprimable

06/10/2009, 15h31
siro1

Fichier .ini et Winform en C++

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 ? :zoubi:

Merci
06/10/2009, 16h17
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.
06/10/2009, 16h21
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/
07/10/2009, 18h25
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.

Citation:

Envoyé par 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.

8O Et les sections, ça sert à quoi d'après toi ??
07/10/2009, 18h53
bacelar

Citation:

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 ? :aie:
07/10/2009, 21h12
Médinoc

Citation:

Envoyé par Mac LAK

8O 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é...
08/10/2009, 10h33
Mac LAK

Citation:

Envoyé par bacelar

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

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...

Citation:

Envoyé par Médinoc

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... ;)
08/10/2009, 10h47
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.
08/10/2009, 10h51
Médinoc

+1 pour Bacelar. L'API de configuration s'occupe elle-même de sauvegarder les paramètres spécifiques à l'utilisateur dans son dossier personnel, et les paramètres des l'EXE dans le répertoire où il se trouve.

@Mac LAK: Par contre, je concède partiellement le point pour le Registre, reconnaissant qu'il est difficile de supprimer les paramètres non-globaux lors de la désinstallation. Le problème, c'est que c'est tout aussi difficile avec des fichiers .ini ou .config, et que RIEN ne couvre les cas extrêmes de désinstallation comme les profils itinérants...
08/10/2009, 11h30
Mac LAK

Citation:

Envoyé par 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.

Mais cela n'est valable qu'en C++/CLI, et pas en C++ "natif".

Citation:

Envoyé par Médinoc

+1 pour Bacelar. L'API de configuration s'occupe elle-même de sauvegarder les paramètres spécifiques à l'utilisateur dans son dossier personnel, et les paramètres des l'EXE dans le répertoire où il se trouve.

Ce qui peut rendre la désinstallation assez comique d'ailleurs si l'on veut supprimer toute trace de l'application : comment aller supprimer les configurations des AUTRES utilisateurs sans être Administrateur ??
Certes, on limite les scories au dossier personnel de chaque utilisateur, mais bon...

Citation:

Envoyé par Médinoc

@Mac LAK: Par contre, je concède partiellement le point pour le Registre, reconnaissant qu'il est difficile de supprimer les paramètres non-globaux lors de la désinstallation. Le problème, c'est que c'est tout aussi difficile avec des fichiers .ini ou .config, et que RIEN ne couvre les cas extrêmes de désinstallation comme les profils itinérants...

Jusqu'à XP inclus, si : tu as la possibilité de spécifier quoi supprimer de façon spécifique dans un désinstalleur (et de choisir de ne pas utiliser la BDR à mauvais escient, bien entendu). Pour ma part, je supprime bien sûr toujours mes fichiers de configuration "attendus", et derrière, je supprime "*.*" dans le dossier de l'application. Au passage, je restaure les clés de registre que j'aurais pu modifier manuellement (je garde une copie de la clé d'origine pour ça).

Avec l'obligation d'utiliser le dossier personnel de l'utilisateur depuis Vista, qui peut donc être itinérant, c'est devenu bien plus difficile à faire sans privilèges d'administration... Sur ce point précis, ce n'est pas forcément une excellente chose d'ailleurs, faudra voir ce que ça donne sur Seven d'ailleurs.
08/10/2009, 11h40
Médinoc

Citation:

Envoyé par Mac LAK

Ce qui peut rendre la désinstallation assez comique d'ailleurs si l'on veut supprimer toute trace de l'application : comment aller supprimer les configurations des AUTRES utilisateurs sans être Administrateur ??

C'est tautologique, là: Si les autres utilisateurs ont des configurations, c'est que l'application a été installée "pour tout le monde", donc en tant qu'administrateur, donc qu'on la désinstalle en tant qu'administrateur.
Seulement, aussi bien en .ini qu'en .config qu'en Registre, impossible de les trouver et les modifier correctement si le profil est itinérant (possible pour les trois s'ils ne le sont pas, même si c'est un poil plus compliqué niveau registre à cause de la nécessité de charger la ruche de chaque utilisateur).

Citation:

Certes, on limite les scories au dossier personnel de chaque utilisateur, mais bon...

Et avec le Registre, on limite les scories au HKCU de chaque utilisateur.

Citation:

Jusqu'à XP inclus, si : tu as la possibilité de spécifier quoi supprimer de façon spécifique dans un désinstalleur (et de choisir de ne pas utiliser la BDR à mauvais escient, bien entendu). Pour ma part, je supprime bien sûr toujours mes fichiers de configuration "attendus", et derrière, je supprime "*.*" dans le dossier de l'application. Au passage, je restaure les clés de registre que j'aurais pu modifier manuellement (je garde une copie de la clé d'origine pour ça).

Avec l'obligation d'utiliser le dossier personnel de l'utilisateur depuis Vista, qui peut donc être itinérant, c'est devenu bien plus difficile à faire sans privilèges d'administration... Sur ce point précis, ce n'est pas forcément une excellente chose d'ailleurs, faudra voir ce que ça donne sur Seven d'ailleurs.

Là, je ne comprends pas ce que tu veux dire, et en quoi XP est différent de Vista sur ce point.

Note: Je parle ici d'une installation et désinstallation locale à un poste, bien entendu. Pour une installation/désinstallation sur tout un domaine, il doit être possible de supprimer la config pour tous les utilisateurs d'un coup...
08/10/2009, 11h44
Médinoc
Idéalement, en supposant que les paramètres et/ou l'installation soient forcément locaux, on pourrait regrouper les paramètres utilisateurs avec l'application plutôt que dans leur dossier itinérant:
- Au niveau fichiers, dans un sous-dossier de CSIDL_PROGRAM_FILES (FOLDERID_ProgramFiles) \ Nom Application dont on aurait correctement réglé les droits d'écriture
- Au niveau registre, dans une sous-clé de HKLM\Software\NomÉditeur\NomApplication dont on aurait correctement réglé les droits d'écriture.
08/10/2009, 12h18
Mac LAK

Citation:

Envoyé par Médinoc

C'est tautologique, là: Si les autres utilisateurs ont des configurations, c'est que l'application a été installée "pour tout le monde", donc en tant qu'administrateur, donc qu'on la désinstalle en tant qu'administrateur.

Et tu fais quoi des applications "propres" pouvant être exécutées librement par tous les utilisateurs sans installation explicite pour "Tous" ?

Citation:

Envoyé par Médinoc

Seulement, aussi bien en .ini qu'en .config qu'en Registre, impossible de les trouver et les modifier correctement si le profil est itinérant (possible pour les trois s'ils ne le sont pas, même si c'est un poil plus compliqué niveau registre à cause de la nécessité de charger la ruche de chaque utilisateur).

D'où l'intérêt, aussi, de ne PAS stocker ces données dans quelque chose de potentiellement mobile. Certes, cela limite l'itinérance des préférences, mais ça augmente la propreté de la machine.

Citation:

Envoyé par Médinoc

Et avec le Registre, on limite les scories au HKCU de chaque utilisateur.

Tout en plombant les perfs générales de la machine... ;) Au moins, le dossier personnel "n'encombre" pas autre chose que la place sur disque.

Citation:

Envoyé par Médinoc

Là, je ne comprends pas ce que tu veux dire, et en quoi XP est différent de Vista sur ce point.

Parce que sur XP, tu peux écrire dans le répertoire d'installation de l'application, tout simplement, ce qui limite fortement les prises de tête sur la désinstallation : l'écriture dans le profil de l'utilisateur est alors un choix, et non pas une obligation.

Citation:

Envoyé par Médinoc

Pour une installation/désinstallation sur tout un domaine, il doit être possible de supprimer la config pour tous les utilisateurs d'un coup...

A part en gardant une trace de TOUS les utilisateurs ayant jamais utilisé le programme sur l'intégralité du domaine pour aller supprimer chaque trace possible sur chaque machine, je ne vois pas trop... Cela reste très lourd à faire, quand même.

Citation:

Envoyé par Médinoc

Au niveau fichiers, dans un sous-dossier de CSIDL_PROGRAM_FILES (FOLDERID_ProgramFiles) \ Nom Application dont on aurait correctement réglé les droits d'écriture

Bravo, t'as réinventé la méthode usuelle sous Win2k / XP... :mouarf:
Ceci étant dit, je n'arrive pas à comprendre la logique derrière ce blocage sous Vista : OK, ça améliore le confort sur les profils itinérants. Mais ce n'est pas la majorité des profils existants, je pense !
J'aurais préféré un sous-répertoire "obligatoire" par application, avec permissions bien sûr, genre "MonAppli\UserData"... Dossier "normal" (et local) pour les utilisateurs "normaux", et mappé vers le profil de l'utilisateur en cas de profil itinérant. Au moins, cela aurait simplifié la vie de tout le monde, développeurs inclus.

Citation:

Envoyé par Médinoc

Au niveau registre, dans une sous-clé de HKLM\Software\NomÉditeur\NomApplication dont on aurait correctement réglé les droits d'écriture.

Dans un cas idéal, tu ne devrais JAMAIS avoir besoin de la base de registre, sauf si tu dois modifier des paramètres système (associations de fichiers notamment). La seule exception est la volonté de pouvoir coopérer avec d'autres applications en indiquant, en BDR, le chemin d'installation (ou, bien mieux, de dernière exécution) du programme afin de pouvoir être "trouvé" facilement sans scanner l'intégralité des disques.
08/10/2009, 12h46
siro1

Bonjour messieurs,

Donc après ce débat interessant . . . Pour en revenir à ma question principale (sujet de la discution)

Sur quelle méthode devrais-je me baser ?

Merci pour vos réponses
:zoubi:
08/10/2009, 12h49
Médinoc

Citation:

Envoyé par Mac LAK

Et tu fais quoi des applications "propres" pouvant être exécutées librement par tous les utilisateurs sans installation explicite pour "Tous" ?

Ils sortent du cadre de cette étude: Installés par n'importe qui (ailleurs que dans Program Files), peuvent être désinstallés par n'importe qui pour eux-mêmes.
Là où ça peut devenir marrant, c'est si une application est installée pour "tous" après que certains utilisateurs l'aient installée pour eux-mêmes)

Citation:

D'où l'intérêt, aussi, de ne PAS stocker ces données dans quelque chose de potentiellement mobile. Certes, cela limite l'itinérance des préférences, mais ça augmente la propreté de la machine.

+1

Citation:

Tout en plombant les perfs générales de la machine... ;) Au moins, le dossier personnel "n'encombre" pas autre chose que la place sur disque.

Ah, je n'ai rien à répondre à cet argument-là.

Citation:

Parce que sur XP, tu peux écrire dans le répertoire d'installation de l'application, tout simplement, ce qui limite fortement les prises de tête sur la désinstallation : l'écriture dans le profil de l'utilisateur est alors un choix, et non pas une obligation.

Sous XP, tout le monde est admin? Cool! :roll:
Sérieusement, impossible de faire ça sans régler les droits, ce qui revient à la méthode que j'ai évoquée ci-dessous.

Citation:

A part en gardant une trace de TOUS les utilisateurs ayant jamais utilisé le programme sur l'intégralité du domaine pour aller supprimer chaque trace possible sur chaque machine, je ne vois pas trop... Cela reste très lourd à faire, quand même.

Fermons cette parenthèse.

Citation:

Bravo, t'as réinventé la méthode usuelle sous Win2k / XP... :mouarf:

Usuelle?
Pour l'instant, le seul programme que j'ai vu faire ça, c'est Steam.

Citation:

Ceci étant dit, je n'arrive pas à comprendre la logique derrière ce blocage sous Vista

C'est bloqué sous Vista? Comment?
(je suis sincère, là: Je n'ai pas de vista sous la main pour tester)

Citation:

OK, ça améliore le confort sur les profils itinérants. Mais ce n'est pas la majorité des profils existants, je pense !
J'aurais préféré un sous-répertoire "obligatoire" par application, avec permissions bien sûr, genre "MonAppli\UserData"... Dossier "normal" (et local) pour les utilisateurs "normaux", et mappé vers le profil de l'utilisateur en cas de profil itinérant. Au moins, cela aurait simplifié la vie de tout le monde, développeurs inclus.

+1

Citation:

Dans un cas idéal, tu ne devrais JAMAIS avoir besoin de la base de registre, sauf si tu dois modifier des paramètres système (associations de fichiers notamment). La seule exception est la volonté de pouvoir coopérer avec d'autres applications en indiquant, en BDR, le chemin d'installation (ou, bien mieux, de dernière exécution) du programme afin de pouvoir être "trouvé" facilement sans scanner l'intégralité des disques.

C'était quand même, à l'époque, la manière recommandée par Microsoft.
Ce qui est pratiquement, en fait, l'unique argument qui pourrait pousser à choisir le Registre plutôt que les fichiers de config pour ses paramètres utilisateur: Tous mes autres arguments étaient neutres.

Mais c'est paradoxal: Sous Windows, on a un Registre alors qu'un exécutable peut retrouver sans problème le répertoire où il se trouve (on va dire OK pour "être trouvé par les autres"), alors que sous *n*x, on n'en a pas, alors qu'un exécutable n'a aucun moyen sûr à 100% de savoir où il est...
08/10/2009, 12h51
Médinoc

Citation:

Envoyé par siro1

Bonjour messieurs,

Donc après ce débat interessant . . . Pour en revenir à ma question principale (sujet de la discution)

Sur quelle méthode devrais-je me baser ?

Merci pour vos réponses
:zoubi:

On est tombé d'accord sur "pas le Registre". Vu que tu programmes déjà en .net, je te conseille l'API de configuration indiquée par Bacelar.
08/10/2009, 14h18
Mac LAK

Citation:

Envoyé par siro1

Sur quelle méthode devrais-je me baser ?

Si tu as beaucoup de choses à sauvegarder, surtout si elles sont plus ou moins pénibles à restaurer, alors un XML.
Si tu es dans un module en C++ natif (non-CLI), genre DLL, ou que tu n'as qu'une ou deux valeurs à sauvegarder/restaurer, alors un .INI sera plus pratique.

Citation:

Envoyé par Médinoc

Sous XP, tout le monde est admin? Cool! :roll:
Sérieusement, impossible de faire ça sans régler les droits, ce qui revient à la méthode que j'ai évoquée ci-dessous.

Je ne crois pas avoir jamais vu un XP où je n'avais pas la possibilité d'écrire dans Program Files, administrateur ou pas, sauf en configuration "Bureau blanc" bien sûr...

Citation:

Envoyé par Médinoc

Usuelle?
Pour l'instant, le seul programme que j'ai vu faire ça, c'est Steam.

Depuis Vista, pour des raisons de compatibilité, ça se réduit. Mais tu avais pas mal de softs qui faisaient ça, en vrac : IrfanView, FileZilla, UltraEdit, Free Download Manager, InnoSetup, et sûrement pas mal d'autres encore que j'ai oublié.

Citation:

Envoyé par Médinoc

C'est bloqué sous Vista? Comment?
(je suis sincère, là: Je n'ai pas de vista sous la main pour tester)

Par défaut, tu n'as pas le droit d'écrire dans Program Files avec Vista si tu n'es pas administrateur. Tu as aussi une virtualisation du répertoire qui interdit d'écrire dessus directement.

Citation:

Envoyé par Médinoc

C'était quand même, à l'époque, la manière recommandée par Microsoft.
Ce qui est pratiquement, en fait, l'unique argument qui pourrait pousser à choisir le Registre plutôt que les fichiers de config pour ses paramètres utilisateur: Tous mes autres arguments étaient neutres.

En fait, MS édicte des "bonnes pratiques"** à chaque version d'OS, notamment pour pallier les abus sur la plate-forme précédente.
A l'origine, utiliser la BDR était prévu pour arrêter la débauche grotesque de .INI dans "C:\Windows", quand ce n'était pas carrément des sections dans le WIN.INI : cela devenait infernal, d'où la BDR... Quelques abus de BDR plus tard, on limite ça en indiquant d'utiliser le répertoire de l'application. De nouveau des abus (propagation de trojans, pollution, etc.), d'où l'utilisation du profil de l'utilisateur.
J'aurais tendance à dire que si certains "développeurs" ne faisaient pas du travail de porc, on n'aurait pas autant de changements lourds dans la manière de "bien se déployer" sous Windows... Tu as d'ailleurs la même chose vis-à-vis de la copie des DLL partagées sous Windows\System(32-64) : là aussi, ça a pas mal évolué depuis Windows 3.1, avec quelques virages à 180° de temps en temps.

** Compte Connect requis.
08/10/2009, 14h29
Médinoc

Citation:

Envoyé par Mac LAK

Je ne crois pas avoir jamais vu un XP où je n'avais pas la possibilité d'écrire dans Program Files, administrateur ou pas, sauf en configuration "Bureau blanc" bien sûr...

Et moi, je me rappelle avoir eu besoin de donner les droits sur des dossiers comme celui de Starcraft, sans quoi les sauvegardes ne marchaient pas pour mon petit frère qui n'était pas admin.
Pouvoir écrire dans Program Files quand on n'est pas admin est l'anomalie, pas le comportement normal.

Citation:

Depuis Vista, pour des raisons de compatibilité, ça se réduit. Mais tu avais pas mal de softs qui faisaient ça, en vrac : IrfanView, FileZilla, UltraEdit, Free Download Manager, InnoSetup, et sûrement pas mal d'autres encore que j'ai oublié.

Par défaut, tu n'as pas le droit d'écrire dans Program Files avec Vista si tu n'es pas administrateur. Tu as aussi une virtualisation du répertoire qui interdit d'écrire dessus directement.

Mais normalement, cela ne change rien au fait qu'un programme d'installation "pour tous" (donc, exécuté par un administrateur) puisse donner les droits sur le sous-dossier en question. J'ai consulté MSDN, la virtualisation ne se produit que si l'ouverture "normale" échoue. De plus, il suffit qu'une application
soit recompilée avec le manifeste pour Vista (ce que Visual 2008 fait par défaut) pour que la virtualisation soit désactivée.
08/10/2009, 14h38
siro1

Entre le .ini et le XML, je penche sur le XML mais que pensez vous des fichier .config ?
08/10/2009, 14h41
Médinoc

XML peut vouloir dire pas mal de choses.

Le fichier .config est lui-même en XML, notamment.
08/10/2009, 14h44
Mac LAK

XML, c'est un format de fichier, et non pas forcément une extension... Regardes le contenu des fichiers .SLN / .VCPROJ / etc. générés par VS2008, via un éditeur de texte : tu verras que ce n'est que de l'XML...
08/10/2009, 15h02
Médinoc

Pas les .sln;
mais les .*proj, les .resx, les .xaml (pour les applications WPF)... et les .config.
08/10/2009, 15h09
Mac LAK

Citation:

Envoyé par Médinoc

Pas les .sln;

Narf, oui, tiens, y'a pas le formalisme XML sur ceux-là... Toutefois, c'est tellement proche que j'ai le gnoeil qui a dû rajouter les "<", "/" et ">" tout seul... :mouarf:

EDIT : y'a aussi les fichiers ".rules", ".vsprops", ".vssettings", les manifestes, les ".user", etc... qui sont des fichiers XML générés par VS.
08/10/2009, 15h13
siro1

donc si j'ai bien compris les .config utilisent le XML.

Cette méthode serait donc adapté à mon besoin ?:roll:
08/10/2009, 15h34
Mac LAK

Citation:

Envoyé par siro1

Cette méthode serait donc adapté à mon besoin ?:roll:

Si tu comptes sauver l'état complet de l'application, c'est à dire (en schématisé) sauver à peu près tout ce qui l'est de façon à ce qu'une fermeture de l'application soit aussi "transparente" qu'une réduction dans la barre des tâches, alors oui, la sauvegarde XML via les fonctions .NET est la meilleure solution.

Si tu veux simplement sauvegarder deux ou trois informations basiques, écrire dans un .INI sera plus rapide à mettre en place.
08/10/2009, 15h52
siro1

Alors je crois que je vais opter pour le .config

En tous cas merci pour vos réponses.

:D