Comment redéfinir l'emplacement de user.config ?

Bonjour à tous.

Je souhaite conserver le fichier dans "C:\Users\nom_utilisateur\AppData\Roaming", mais je voudrais redéfinir le chemoin par défaut généré par VB :

Code:

---

1 2 3

...AppData\Roaming\mon_appli.exe_Url_ertfy25skgskdflkglmskdkerlklg44y\version\user.config ' EN -> ...AppData\Roaming\mon_appli\user.config

---

car mon application enregistre déjà d'autres données à l'emplacement suivant :

...AppData\Roaming\mon_appli\sous-dossier\

Ainsi, les dossiers serait fusionnés et cela faciliterait la mise à jour des versions suivantes de mon appli.

J'ai passé la journée à faire des recherches sans trouver la solution à mon problème. A vrai dire, si j'ai bien compris, il semblerait que la modification soit impossible, mais en désespoir de cause...

En tout cas ce truc me rend dingue ! Pourquoi faire simple, quand on peut faire compliqué... C'est franchement dommage, car My.settings est facile à mettre en oeuvre.

D'avance merci à ceux qui auront un début de réponse et puis aux autres aussi en fait ;)

Peut-être une piste du coté de ApplicationSettingsBase
http://msdn.microsoft.com/en-us/libr...ase.aspx#Y2280

Tout ça me donne envie de lancer un p'tit sondage sur la technique employée par chacun pour la sauvegrade des données utilisateurs ;)

Bonjour,

Je n'ai aucune idée s'il est possible de changer le chemin.

Mais les premiers résultats de google pour : My.settings vb.net - Google Search.
m'ont donné cet article qui montre comment faire une classe personnalisée “Serializable” dans une extension “My.Preferences”.

Cela peut-être une bonne alternative rapide si vous ne trouvez pas comment changer le chemin de My.settings...

P.S. : Bien joué le sondage avec le lien sur ce message :aie:

On ne peut pas changer l'emplacement (du moins pas sans faire des grosses bidouilles) ; c'est pour ça que j'utilise pas ça. Je préfère utiliser des classes perso sérialisées en XML, ça prend 2 minutes et c'est plus pratique.

Merci les gars !

Avec cette histoire, j'ai donc 2 dossiers pour mon appli dans AppData. J'aime pas bien ça, mais bon... J'ai terminé le développement de l'appli, alors il est un peu tard pour changer de technique, d'autant que ça fonctionne bien en l'état.

La prochaine fois j'opterais sans doute pour un fichier XML perso. Par contre j'ai fait des essais et je trouve ça un peu difficile quand même (je n'avais encore jamais manipulé de fichier XML). Avant je faisais ça à la barbare dans un fichier txt et après j'ai découvert My.Settings

De toutes façons je vais bien devoir m'y mettre, car le XML est devenu un standard incontournable visiblement.

Citation:

---

Envoyé par arnomedia

La prochaine fois j'opterais sans doute pour un fichier XML perso. Par contre j'ai fait des essais et je trouve ça un peu difficile quand même (je n'avais encore jamais manipulé de fichier XML).

---

Tu analyses le fichier "à la main" ou tu utilises la sérialisation XML ? Avec la sérialisation c'est super facile ;)

J'suis pas bien fin alors, parce que j'ai utilisé la serialisation :) J'ai réussi à créer le fichier comme je voulais (une copie du formattage de user.config) mais je me suis arreté parce qu'il falait gérer les modifs, ajouter un bout de code à chaque lecture d'un noeud... et vu que mon fichier de config contient pas mal de données dont une liste (pas essayé ça)... Faut dire que je suis pas super à l'aise non plus avec les class perso et les propriétés. Jusqu'a présent je m'en suis passé. Il m'a fallut d'abord assimiler les bases. VB.NET est le premier language que j'ai appris et je ne viens pas du monde informatique à la base. C'est la passion, une forte envie d'apprendre et aussi l'aide des membres de Developpez.com qui m'aident à progresser un peu plus à chaque projet que j'entreprends.

Cela dit, j'ai mis la sérialisation XML en haut de ma liste des trucs à maitriser ;) D'autant que ça me sera utile aussi pour le web.

Rien à voir, mais j'arrive pas à bien comprendre l'intéret des propriétés. J'ai justement voulu les utiliser dans une class perso aujourd'hui et puis n'étant pas super convaincu de l'intéret de la chose dans le cas précis, je me suis reporté sur une structure que j'ai finalement laissé tomber pour finir avec une fonction toute simple ;) Le but était d'envoyer une chaine d'arguments "pré-formatés" à un .EXE sans avoir à les "écrire" pour éviter les fautes de frappes. Pour l'instant, j'ai l'impression (et je dois me tromper) que les proprietés et les fonctions font double emploi.

Bonjour,

Citation:

---

j'ai l'impression (et je dois me tromper) que les proprietés et les fonctions font double emploi

---

Effectivement, ça n'a pas du tout le même emploi.

Normalement, tu crée ta Classe qui contient ta structure (propriétés), et ensuite tu ajoute des méthodes (fonctions).
Après tu n'est pas censé donné un accès total à tes variables (propriétés),
mais seulement retourner des valeur (boolean, int, ...) avec tes méthodes.

Quel intérêt?
permettre à ta classe d’être partagé avec tout le monde.

Moi perso je fait mes classes uniquement pour ordonner mes données,
donc les méthodes, elle passent à la trappe. C'est mal je sais :oops:

Citation:

---

Envoyé par arnomedia

Rien à voir, mais j'arrive pas à bien comprendre l'intéret des propriétés.

---

http://tlevesque.developpez.com/tuto...t-importantes/

Merci pour le lien. C'est pas super clair quand même... ;)

Du coup, si j'ai bien compris l'explication de hunteshiva, une propriété se comporte un peu comme une variable globale modifiée par une méthode suivant certaines conditions définies dans la méthode en question ? Dans ce cas la propriété offre plus de souplesses, puisqu'il serait possible d'inclure des conditions qui influenceraient la valeur (Set) et idem pour (Get). C'est ça ou j'ai tout faux ?

Si jamais, j'aime bien les exemples... :)

Donc, il ne faut pas faire:

Code:

---

1 2 3

Public var As Boolean = CheckBox.checkState OU Public totalVar As Integer = var1 + var2

---

mais utiliser une propriété si on sait que var1 et var2 peuvent être modifiées à plusieurs endroits dans l'application. Et pour en remettre une dernière couche, la propriété est idéale pour faire passer une valeur d'un formulaire à un autre, c'est ça ? Mais alors, c'est un peu une variable par référence, non ?

Citation:

---

Envoyé par arnomedia

Merci pour le lien. C'est pas super clair quand même... ;)

---

En fait cet article suppose que tu sais ce que c'est qu'une propriété, et explique pourquoi il vaut mieux utiliser des propriétés que des champs (variables de classes)

Si tu n'est pas familier avec la notion de propriété, regarde plutôt sur MSDN.

Citation:

---

Envoyé par arnomedia

Du coup, si j'ai bien compris l'explication de hunteshiva, une propriété se comporte un peu comme une variable globale modifiée par une méthode suivant certaines conditions définies dans la méthode en question ? Dans ce cas la propriété offre plus de souplesses, puisqu'il serait possible d'inclure des conditions qui influenceraient la valeur (Set) et idem pour (Get). C'est ça ou j'ai tout faux ?

---

Pourquoi "globale" ?

Une propriété, c'est simplement 2 méthodes (get/set) regroupées ensemble sous un nom commun. C'est juste la formalisation des accesseurs/mutateurs (getToto/setToto) qu'on trouve dans d'autres langages comme Java. Dans ces méthodes, tu peux contrôler la valeur affectée à la propriété, déclencher une notification de changement, gérer l'initialisation tardive, etc.

Citation:

---

Envoyé par tomlev

Pourquoi "globale" ?

---

Dans le sens où elle est accessible par l'ensemble des méthodes d'une class.

Il se trouve que je suis en train de m'exercer dessus depuis quelques minutes sans vraiment savoir s'il est judicieux d'en utiliser une. Par habitude, j'aurais déclaré une variable globale à la place. Je pense avoir compris le fonctionnement d'une proriété, mais honetement par l'intéret. J'ai pas la prétention de dire qu'il n'y en a pas, mais qu'est-ce qu'apporte une propriété de plus par rapport à une variable globale ?

Si je comprends bien, il est inutile d'utiliser une propriété telle qu'elle est formaté par un double TAB ds l'IDE de Microsoft. Dans ce cas autant utiliser une variable globale, non ? L'intéret est donc d'y ajouter des conditions par exemple et dans ce cas, la propriété ressemble étrangement à une fonction un peu bridé (puisque juste un paramètre ByVal). Je ne comprends pas ce que je ne comprends pas :)

Citation:

---

Envoyé par arnomedia

Il se trouve que je suis en train de m'exercer dessus depuis quelques minutes sans vraiment savoir s'il est judicieux d'en utiliser une. Par habitude, j'aurais déclaré une variable globale à la place. Je pense avoir compris le fonctionnement d'une proriété, mais honetement par l'intéret. J'ai pas la prétention de dire qu'il n'y en a pas, mais qu'est-ce qu'apporte une propriété de plus par rapport à une variable globale ?

---

Il n'y a pas de variables globales... je suppose que tu parles des variables de classe (champs) ?

Pour ce que ça apporte, je l'ai déjà dit plus haut. Ça permet de contrôler les accès depuis l'extérieur de la classe (principe d'encapsulation). D'autre part, les mécanismes de binding de Windows Forms ou WPF ne permettent de se lier qu'à des propriétés, pas à des champs. C'est expliqué plus en détails dans l'article que je t'ai indiqué.

Grosso modo, tu peux appliquer la règle suivante :
- Si c'est public, utilise toujours une propriété
- Si c'est privé, utilise plutôt un champ, sauf si une propriété t'arrange mieux

Citation:

---

Envoyé par arnomedia

Si je comprends bien, il est inutile d'utiliser une propriété telle qu'elle est formaté par un double TAB ds l'IDE de Microsoft. Dans ce cas autant utiliser une variable globale, non ?

---

Non, justement ! En fait, l'intérêt est que si c'est déjà une propriété (même si elle ne fait rien de plus que l'implémentation par défaut), tu peux toujours modifier son implémentation plus tard sans que ça impacte le code existant. Alors que si tu crées un champ au début, et que plus tard tu décides d'en faire une propriété, du code externe qui dépendait du fait que ce soit un champ ne va plus fonctionner. Donc autant créer une propriété dès le départ pour éviter ce genre de problème.

Citation:

---

Envoyé par arnomedia

Je ne comprends pas ce que je ne comprends pas :)

---

Moi non plus :aie:

Citation:

---

Envoyé par tomlev

Il n'y a pas de variables globales... je suppose que tu parles des variables de classe (champs) ?

---

Quand je parle de variable globale, je parle de ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Class truc Public var as string ' -> variable globale   Sub main() 'code.... var = "mon super machin" End Sub End Class   Class bidule Sub main() 'code... myTextBox.Text = truc.var End Sub End Class

---

Je fonctionne souvent comme ça pour faire passer une valeur d'un formulaire à l'autre. Souvent j'ai aussi 2 ou 3 variables dans un module que j'utilise en générale comme des constantes, sinon ça serait un peu "dangereux".

Le formulaire sur lequel je travaille reprend le principe de mon exemple. Il a une variable public string qui contient le nom d'un fichier à modifier. Cette variable est défini dans le formulaire appelant. Le Formulaire sur lequel je travaille me sert dans 2 situations.
1. pour créer un nouveau fichier
2. pour renommer un fichier existant

Donc :
IF ma variable est vide THEN nouveau document
ELSE document à modifier avec le nom du document qui doit l'être.

Pour mon histoire de propriété ou pas il s'agit d'autre chose.

En tout cas merci pour le mal que tu te donnes, c'est sympa !

Quand tu parle de "champs", tu parle d'un TextBox, cells, ComboBox ou encore Input pour le web et autre drolerie ou là aussi je suis à coté de la plaque ? ;)

Citation:

---

Envoyé par arnomedia

Quand je parle de variable globale, je parle de ça :

---

C'est bien ce que j'avais compris ; mais ça ne s'appelle pas une variable globale, ça s'appelle un champ (aussi appelé variable de classe)

Et je confirme que dans ce cas, ça devrait être une propriété et non un champ. Évidemment si c'est une toute petite application sans interaction avec du code externe, ce n'est pas très grave, mais c'est une bonne pratique d'utiliser des propriétés plutôt que des champs publics. Il pourrait y avoir des contraintes sur ta variable var, et si n'importe quelle classe peut la modifier directement, la classe truc ne peut pas imposer le respect de ces contraintes. Alors qu'avec une propriété tu as la possibilité de contrôler la valeur affectée, et éventuellement d'y réagir d'une manière ou d'une autre.

Citation:

---

Envoyé par arnomedia

Quand tu parle de "champs", tu parle d'un TextBox, cells, ComboBox ou encore Input pour le web et autre drolerie ou là aussi je suis à coté de la plaque ? ;)

---

Non, c'est pas un champ de formulaire, mais un champ au sens d'un élément du langage, un "attribut" de la classe (quoique ce terme n'est pas très approprié vu qu'il désigne autre chose en .NET.
D'ailleurs, les contrôles sont déclarés dans la classe comme des champs (privés par défaut)

Encore un lien utile :
http://msdn.microsoft.com/fr-fr/library/sk5e8eth

Slt tomlev !

Comme la dernière fois, j'ai fini par utiliser une fonction à défaut de mieux. Je suis pris par le temps, mais j'ai pas dit mon dernier mot ;)J'essaierais à nouveau d'utiliser les propriétés sur un projet test, car autant faire les choses dans les règles de l'art.

Encore merci !

A bientôt.

Un autre lien intéressant : http://plasserre.developpez.com/cours/vb-net/?page=poo1