Utilisation de My.Settings

bonjour,

Je cherche à lire et écrire programmatiquement dans les paramètres de l'application (onglet Paramètres du projet sus Visual studio et My.Settings en VB.NET).

Lorsque je fais :

Code:

---

1 2	My.Settings.Database = "toto" My.Settings.Save()

---

Nota : je me suis inspiré de ce topic qui ressemble en gros à ce que je veux faire.

Je ne retrouve pas "toto" en face du paramètre Database dans l'onglet Paramètres de VS2010.
Pourtant par le code, je vérifie que la valeur est bien conservée et réutilisée à chaque utilisation de l'appli.

est-ce normal ?
EDIT : si c'est normal, je me demande où sont stockés ces paramètres.

Confirmez-vous que l'on ne peut pas modifier programmatiquement un paramètre de type (Chaîne de Connection) et qu'il faut donc utiliser un paramètre de type string pour les connections aux bases de données si l'on souhaite modifier ce paramètre en cours d'appli ?

Dans ce cas, j'ai un autre problème : pour fonctionner, mon dataset typé qui représente l'ensemble de ma BdD (l'onglet XSD) fait référence à cette fameuse chaîne de connexion. Si je change sont type en String, le dataset typé ne se charge plus...

Bonsoir noftal,

lorsque tu enregistres ton paramètre il est inscrit sur ton disque dur dans un fichier nommé "user.config" situé dans ce chemin :

"C:\Users\%USERNAME%\AppData\Local\%YOUR_APP_NAME%\........."

Si tu t'attends à trouver dans l'EDI la valeur "toto" dans le tableau alors tu peux toujours attendre ça ne fonctionne pas ainsi !
La valeur est utilisée par l'application lors de l'exécution et non dans l'EDI.

Si tu vois apparaître une valeur dans les paramètres de ton projet alors ça veut tout simplement dire que tu as mis une valeur par défaut.

Voilà pour ta première question. Pour le reste je laisse le soin aux spécialistes de te répondre.

Bonne soirée.

je confirme

après c'est rarement le 1er choix, mais néanmoins sur des petits projets ca peut suffire (et ca fonctionne donc ^^)

par contre pour pouvoir modifier ces paramètres, il faut qu'ils soient de type "Utilisateur" et pas du type "Application"
par défaut ils sont en mode application, et là ca n'est pas modifiable (ca serait donc totalement inutile)

et ca créé en effet un fichier xml dans un dossier de l'utilisateur ; changer l'exe de machine reprend donc le paramètre par défaut

Alors justement, le fait que ces paramètres soient enregistrés pour chaque utilisateur me pose un pb.
Pour vous faire comprendre, je dois donc vous exposer mon besoin fonctionnel.
Mon appli fonctionne autour d'une base de données locale. Il s'agit d'une gestion de bibliothèque.
Lorsque l'utilisateur lance l'appli pour la première fois, l'appli doit vérifier si une base a été déjà renseignée (1). Sinon, il demande à l'utilisateur à quel endroit il souhaite implanter le fichier de bdd (2). Une fois ceci fait l'appli doit donc directement interroger la bdd là où elle se trouve et les étapes 1 et 2 sont sautées.

Pour 1 et 2 voici les solutions que j'avais imaginées :
(1) : test sur la chaine ConnectionString implantée dans les paramètres du projet de type (chaîne de connection), paramètre au niveau de l'appli. Si cette chaine est vide on passe à 2
(2) : on stocke dans ConnectionString le chemin d'accès à la bdd spécifié par l'utilisateur et on copie une BdD vierge stockée dans les "resources" vers l'emplacement désigné.

Il ne faut pas que, si je change d'utilisateur, une autre bdd soit créée d'où mon objection initiale.

Cependant la solution évoquée ne marche pas. Comme vous l'avez dit, on ne peut pas modifier un paramètre de portée "application".

Donc, par rapport à cette exposé, avez-vous une solution à suggérer ?

my.Settings n'est qu'une des solutions possibles pour avoir des paramètres
et comme je l'ai dit elle est rarement utilisée, on le voit elle ne sied pas à ton cas
utilise donc autre chose comme un fichier à côté de l'exe (.ini, .xml)
la sérialisation xml est pratique pour quelques paramètres, ca fait peu de code à écrire

Bonjour noftal,

Pourquoi ne pas utiliser 1 fichier de configuration ".ini" ou ".xml" ?

Bien qu'un simple fichier ".ini" devrait suffire pour stocker aussi peu de paramètres...


PS :
le fichier de paramètres du type "user.config" a ses limites : lorsque tu décides de mettre à jour ton programme alors le fichier de config existant ne peut plus être utilisé car son répertoire racine est une sorte de hachage généré à partir des informations suivantes ; ProductName, ProductVersion, ...etc....

A+


EDIT : Pol63 a été plus rapide ......:roll::roll:;)

N'ayant pas de connaissance sur les fichiers INI ou XML (ni sur la sérialisation), je me suis orienté vers le stockage des paramètres dans le registre que je maîtrise un peu déjà.
Cela dit, il souvent conseillé de stocker les paramètres dans HKEY_CURRENT_USER alors que, dans mon cas, il vaudrait mieux stocker ma chaine de connexion dans HKEY_LOCAL_MACHINE si j'ai bien compris

La manipulation d'un fichier de config de type ".ini" est très simple, le fonctionnement reste le même que le registre.

Voilà un lien qui devrait te montrer comment ça fonctionne :

http://www.developpez.net/forums/d11...i/#post7472174


A+

Citation:

---

Envoyé par noftal

N'ayant pas de connaissance sur les fichiers INI ou XML (ni sur la sérialisation), je me suis orienté vers le stockage des paramètres dans le registre que je maîtrise un peu déjà.

---

si tu ne fais que ce que tu sais faire sans rien apprendre tu peux laisser tomber le développement ...

Citation:

---

Envoyé par wallace1

La manipulation d'un fichier de config de type ".ini" est très simple, le fonctionnement reste le même que le registre.

Voilà un lien qui devrait te montrer comment ça fonctionne :

http://www.developpez.net/forums/d11...i/#post7472174


A+

---

Merci pour l'info. Cela rejoint le tuto de P. Lasserre qui donne aussi les éléments pour faire.
Dans le cas d'un fichier INI, je me pose la question de son lieu de stockage.
- en phase de développement sous VS.
- une fois l'appli diffusée.
Avez-vous des recommandations en la matière car aucun des 2 tutos n'apporte ce type de réponse ?

Citation:

---

Envoyé par noftal

Merci pour l'info. Cela rejoint le tuto de P. Lasserre qui donne aussi les éléments pour faire.

---

Tuto par lequel pas mal de personne sont passés pour débuter leur apprentissage.
Par ailleurs je te recommande d'en faire de même ainsi tu te serais rendu compte que mon exemple a été étoffé de fonctions que P. Lasserre n'a pas introduit pour conserver l'aspect formateur de son excellent tuto : (http://plasserre.developpez.com/cour...-forms4#LX-N-2).

Citation:

---

Envoyé par noftal

Dans le cas d'un fichier INI, je me pose la question de son lieu de stockage.
- en phase de développement sous VS.
- une fois l'appli diffusée.
Avez-vous des recommandations en la matière car aucun des 2 tutos n'apporte ce type de réponse ?

---

Tu ne trouveras pas toujours toutes les réponses à tes questions dans des tutos !
Il faut parfois faire preuve de bon sens. ;)


Bonne continuation.

@wallace1 et Pol63

1°/ J'ai lu le tuto de P. LASSERRE de bout en bout (1100 pages). Je ne suis pas sûr qu'on puisse en dire autant de beaucoup de monde parmi les débutants qui postent des questions sur le forum. J'ai parfaitement vu qu'il contenait les indications nécessaires pour apprendre à utiliser un fichier Ini ou XML. Mais cela nécessite de l'apprentissage (il ne suffit pas de lire...) que j'étale dans le temps en fonction des priorités. Si je maîtrise déjà une méthode similaire, il est donc naturel que je m'y raccroche.

2°/ Le bon sens est une notion subjective et n'a pas beaucoup de sens quand on est en apprentissage informatique. Je ne prétends pas être un expert en tout. Donc ce qui vous paraît évident ne l'est pas forcément pour moi.

3°/ Un forum est fait pour partager des expériences. Si cela vous fatigue, ce que je peux comprendre, passez votre chemin plutôt que de donner des leçons de moralité. Vous gagnerez du temps. De mon côté, je m'efforce de répondre à des topics dans la mesure de mes connaissances qui sont encore assez limitées, certes. C'est ma façon de remercier ceux qui m'ont aidé en répondant à mes propres questions.

Noftal,

C'est tout à ton honneur d'avoir parcouru toutes ces pages mais leur compréhension et assimilation est un autre débat.

Tu peux lire autant de pages que tu veux mais ce qui est certains c'est que ce qui saute aux yeux tu ne le vois pas :

Pol63 avait déjà répondu à ta dernière interrogation dans un précédent post :

Citation:

---

......
utilise donc autre chose comme un fichier à côté de l'exe (.ini, .xml)
......

---

Nul besoin de tergiverser les leçons de vie et moralité je les donne à mes enfants.


Bonne continuation.

comme tu le dis beaucoup ne prennent pas le temps de lire des tutos, aussi il faut bien une méthode pour faire le tri dans les posts sur lesquels on peut passer un peu de temps
ta réponse est en sens satisfaisante, il faut des années pour tout connaitre et on utilise en effet ce qu'on connait

concernant le bon sens, certaines choses sont faites naturellement avec de l'expérience, néanmoins il y a toujours des choses à trancher même après des années d'expérience, le but d'un développeur n'est pas seulement d'acquérir des connaissances, mais aussi de développer une capacité de réflexion

concernant le fichier ini (ou autre), en réfléchissant on a 2 possibilités au départ : livrer le fichier ou le créer lors du 1er démarrage
livrer le fichier est absurde puisque le chemin sera surement faux, le créer s'il n'existe pas convient donc
concernant l'emplacement de celui ci on a tout le disque dur au choix, néanmoins il faut que ca soit un fichier accessible par tous ceux qui utiliseront l'application, et qui en auront donc le droit, donc mettre le fichier à côté de l'exe convient car c'est le même dossier
en debug vs le .exe qu'il vient de créér, qui se trouve dans bin\debug ou bin\release, le fichier sera donc créé à côté et ca ne pose pas de problème

Merci :ccool: