Dans un contrôle Label.Caption j'ai l'adresse d'un fichier à ouvrir.
J'ai également un bouton qui active un InputBox ou l'utilisateur peut
changer l'adresse du Label.Caption si necessaire.
Je voudrais que le Label.Caption garde en mémoire la nouvelle adresse donné
pour les utilisation futur du prog.; ce qui n'est pas le cas actuellement.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Marc
"Christian" a écrit dans le message de news:
Bonjour,
Dans un contrôle Label.Caption j'ai l'adresse d'un fichier à ouvrir. J'ai également un bouton qui active un InputBox ou l'utilisateur peut changer l'adresse du Label.Caption si necessaire.
Je voudrais que le Label.Caption garde en mémoire la nouvelle adresse
donné
pour les utilisation futur du prog.; ce qui n'est pas le cas actuellement.
Hello,
l'astuce consiste à sauvegarder dans un fichier local à l'application la valeur courante du label.
On initialise le contenu du label au lancement de l'application, avec la procédure InitLabel
A chaque modification par l'utilisateur, on sauve dans le fichier la nouvelle valeur (en écrasant l'ancienne). C'est ce que fait la procédure SaveLabel.
Exemple: Il faut un label (Label1) et un bouton (Command1) Voici le code:
8<---------------------------
Option Explicit
Private Sub Command1_Click() Dim s As String
s = InputBox("nom du chemin : ") If s <> "" Then Label1.Caption = s Call SaveLabel(s) End If
End Sub
Private Sub form_load() Call InitLabel End Sub
Private Sub SaveLabel(ByVal s As String) Dim f As Integer
f = FreeFile Open App.Path & "sauve.txt" For Output As #f Print #f, s Close #f
End Sub
Private Sub InitLabel() Dim f As Integer Dim s As String
On Error GoTo no_fic
f = FreeFile Open App.Path & "sauve.txt" For Input As #f Line Input #f, s Label1.Caption = s Close #f tchao: Exit Sub no_fic: Resume tchao End Sub
8<---------------------------
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"Christian" <christian.neu@tele2.fr> a écrit dans le message de
news:OZF10L1dFHA.584@TK2MSFTNGP15.phx.gbl...
Bonjour,
Dans un contrôle Label.Caption j'ai l'adresse d'un fichier à ouvrir.
J'ai également un bouton qui active un InputBox ou l'utilisateur peut
changer l'adresse du Label.Caption si necessaire.
Je voudrais que le Label.Caption garde en mémoire la nouvelle adresse
donné
pour les utilisation futur du prog.; ce qui n'est pas le cas actuellement.
Hello,
l'astuce consiste à sauvegarder dans un fichier local
à l'application la valeur courante du label.
On initialise le contenu du label au lancement de l'application,
avec la procédure InitLabel
A chaque modification par l'utilisateur, on sauve dans le fichier
la nouvelle valeur (en écrasant l'ancienne). C'est ce que fait la procédure
SaveLabel.
Exemple:
Il faut un label (Label1) et un bouton (Command1)
Voici le code:
8<---------------------------
Option Explicit
Private Sub Command1_Click()
Dim s As String
s = InputBox("nom du chemin : ")
If s <> "" Then
Label1.Caption = s
Call SaveLabel(s)
End If
End Sub
Private Sub form_load()
Call InitLabel
End Sub
Private Sub SaveLabel(ByVal s As String)
Dim f As Integer
f = FreeFile
Open App.Path & "sauve.txt" For Output As #f
Print #f, s
Close #f
End Sub
Private Sub InitLabel()
Dim f As Integer
Dim s As String
On Error GoTo no_fic
f = FreeFile
Open App.Path & "sauve.txt" For Input As #f
Line Input #f, s
Label1.Caption = s
Close #f
tchao:
Exit Sub
no_fic:
Resume tchao
End Sub
8<---------------------------
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
Dans un contrôle Label.Caption j'ai l'adresse d'un fichier à ouvrir. J'ai également un bouton qui active un InputBox ou l'utilisateur peut changer l'adresse du Label.Caption si necessaire.
Je voudrais que le Label.Caption garde en mémoire la nouvelle adresse
donné
pour les utilisation futur du prog.; ce qui n'est pas le cas actuellement.
Hello,
l'astuce consiste à sauvegarder dans un fichier local à l'application la valeur courante du label.
On initialise le contenu du label au lancement de l'application, avec la procédure InitLabel
A chaque modification par l'utilisateur, on sauve dans le fichier la nouvelle valeur (en écrasant l'ancienne). C'est ce que fait la procédure SaveLabel.
Exemple: Il faut un label (Label1) et un bouton (Command1) Voici le code:
8<---------------------------
Option Explicit
Private Sub Command1_Click() Dim s As String
s = InputBox("nom du chemin : ") If s <> "" Then Label1.Caption = s Call SaveLabel(s) End If
End Sub
Private Sub form_load() Call InitLabel End Sub
Private Sub SaveLabel(ByVal s As String) Dim f As Integer
f = FreeFile Open App.Path & "sauve.txt" For Output As #f Print #f, s Close #f
End Sub
Private Sub InitLabel() Dim f As Integer Dim s As String
On Error GoTo no_fic
f = FreeFile Open App.Path & "sauve.txt" For Input As #f Line Input #f, s Label1.Caption = s Close #f tchao: Exit Sub no_fic: Resume tchao End Sub
8<---------------------------
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
Clive
On pourra aussi utiliser SaveSettins et GetSetting qui a l'avantage d'être 1) dans la Base de Registres, 2) d'être personalisé pour chaque client du poste.
Dans le Form_Load Fichier=GetSetting("Nom de mon Prog", "Nom de la branche","Nom de la Clé","Valeur par Défaut") if Fichier= "Valeur par Défaut" then 'Clé n'existe pas Label.caption="" else Label.caption="Fichier Endif
Dans le Form_unload if label.caption <>"" then SaveSetting "Nom de mon Prog", "Nom de la branche","Nom de la Clé",label.caption endif
On pourra aussi utiliser SaveSettins et GetSetting qui a l'avantage
d'être 1) dans la Base de Registres, 2) d'être personalisé pour
chaque client du poste.
Dans le Form_Load
Fichier=GetSetting("Nom de mon Prog", "Nom de la branche","Nom de la
Clé","Valeur par Défaut")
if Fichier= "Valeur par Défaut" then 'Clé n'existe pas
Label.caption=""
else
Label.caption="Fichier
Endif
Dans le Form_unload
if label.caption <>"" then
SaveSetting "Nom de mon Prog", "Nom de la branche","Nom de la
Clé",label.caption
endif
On pourra aussi utiliser SaveSettins et GetSetting qui a l'avantage d'être 1) dans la Base de Registres, 2) d'être personalisé pour chaque client du poste.
Dans le Form_Load Fichier=GetSetting("Nom de mon Prog", "Nom de la branche","Nom de la Clé","Valeur par Défaut") if Fichier= "Valeur par Défaut" then 'Clé n'existe pas Label.caption="" else Label.caption="Fichier Endif
Dans le Form_unload if label.caption <>"" then SaveSetting "Nom de mon Prog", "Nom de la branche","Nom de la Clé",label.caption endif
Jean-Marc
"Clive" a écrit dans le message de news:
On pourra aussi utiliser SaveSettins et GetSetting qui a l'avantage d'être 1) dans la Base de Registres, 2) d'être personalisé pour chaque client du poste.
Hello,
1) A mon humble avis, la base de registre ne possède aucun avantages mais uniquement des inconvénients; la liste de ceux-ci est trop longue pour être énumérée ici :-))
<HS> Si en fait, il y a UNE bonne raison d'utiliser la BdR: C'est si tu veux bruler en enfer pour toujours. </HS>
2) C'est vrai que c'est une bonne idée de pouvoir personnaliser par client du poste. On peut bien sur le faire de façon propre et saine avec un fichier de configuration:
; Config par utilisateurs [Jean-marc] path=c:trucmachin
[Christine] path=c:bidulebrol
[Invité] path=d:guestmisc
On récupérera simplment le user de la personne connectée et on créera dans le fichier de config les entrées idoines.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"Clive" <clumb@free.fr> a écrit dans le message de
news:1119607904.895322.7110@g43g2000cwa.googlegroups.com...
On pourra aussi utiliser SaveSettins et GetSetting qui a l'avantage
d'être 1) dans la Base de Registres, 2) d'être personalisé pour
chaque client du poste.
Hello,
1) A mon humble avis, la base de registre ne possède aucun
avantages mais uniquement des inconvénients; la liste de
ceux-ci est trop longue pour être énumérée ici :-))
<HS>
Si en fait, il y a UNE bonne raison d'utiliser la BdR:
C'est si tu veux bruler en enfer pour toujours.
</HS>
2) C'est vrai que c'est une bonne idée de pouvoir personnaliser
par client du poste. On peut bien sur le faire de façon propre
et saine avec un fichier de configuration:
; Config par utilisateurs
[Jean-marc]
path=c:trucmachin
[Christine]
path=c:bidulebrol
[Invité]
path=d:guestmisc
On récupérera simplment le user de la personne connectée
et on créera dans le fichier de config les entrées idoines.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
On pourra aussi utiliser SaveSettins et GetSetting qui a l'avantage d'être 1) dans la Base de Registres, 2) d'être personalisé pour chaque client du poste.
Hello,
1) A mon humble avis, la base de registre ne possède aucun avantages mais uniquement des inconvénients; la liste de ceux-ci est trop longue pour être énumérée ici :-))
<HS> Si en fait, il y a UNE bonne raison d'utiliser la BdR: C'est si tu veux bruler en enfer pour toujours. </HS>
2) C'est vrai que c'est une bonne idée de pouvoir personnaliser par client du poste. On peut bien sur le faire de façon propre et saine avec un fichier de configuration:
; Config par utilisateurs [Jean-marc] path=c:trucmachin
[Christine] path=c:bidulebrol
[Invité] path=d:guestmisc
On récupérera simplment le user de la personne connectée et on créera dans le fichier de config les entrées idoines.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
Clive
Hello Jean-Marc,
1) Bien que je respecte ton opinion (et ton droit de l'avoir), je meurs d'impatience de lire cette liste des inconvénients liés à l'utilisation de SaveSetting/GetSetting... dis-nous tout !
2) Un problème avec la "personalisation" d'un fichier .ini est que cela impose de démander le nom de l'utilisateur à chaque lancement, sauf si on essaie de récuperer le nom de login. Cela devient rapidement une vrai usine à gaz.
Je suis d'accord que "bricoler" dans la BdR peut donner des résultats inattendus, mais l'utilsation de SaveSetting/GetSetting est très simpe et, autant que je sache, très sûr. J'ai aussi l'impression que de moins en moins de logiciels utilisent les fichiers ini, sauf ceux qui sont multi-platforme.
Clive
Hello Jean-Marc,
1) Bien que je respecte ton opinion (et ton droit de l'avoir), je meurs
d'impatience de lire cette liste des inconvénients liés à
l'utilisation de SaveSetting/GetSetting... dis-nous tout !
2) Un problème avec la "personalisation" d'un fichier .ini est que
cela impose de démander le nom de l'utilisateur à chaque lancement,
sauf si on essaie de récuperer le nom de login. Cela devient
rapidement une vrai usine à gaz.
Je suis d'accord que "bricoler" dans la BdR peut donner des résultats
inattendus, mais l'utilsation de SaveSetting/GetSetting est très simpe
et, autant que je sache, très sûr. J'ai aussi l'impression que de
moins en moins de logiciels utilisent les fichiers ini, sauf ceux qui
sont multi-platforme.
1) Bien que je respecte ton opinion (et ton droit de l'avoir), je meurs d'impatience de lire cette liste des inconvénients liés à l'utilisation de SaveSetting/GetSetting... dis-nous tout !
2) Un problème avec la "personalisation" d'un fichier .ini est que cela impose de démander le nom de l'utilisateur à chaque lancement, sauf si on essaie de récuperer le nom de login. Cela devient rapidement une vrai usine à gaz.
Je suis d'accord que "bricoler" dans la BdR peut donner des résultats inattendus, mais l'utilsation de SaveSetting/GetSetting est très simpe et, autant que je sache, très sûr. J'ai aussi l'impression que de moins en moins de logiciels utilisent les fichiers ini, sauf ceux qui sont multi-platforme.
Clive
Patrick Philippot
Bonjour,
Clive wrote:
2) Un problème avec la "personalisation" d'un fichier .ini est que cela impose de démander le nom de l'utilisateur à chaque lancement, sauf si on essaie de récuperer le nom de login. Cela devient rapidement une vrai usine à gaz.
Je suis d'accord que "bricoler" dans la BdR peut donner des résultats inattendus, mais l'utilsation de SaveSetting/GetSetting est très simpe et, autant que je sache, très sûr. J'ai aussi l'impression que de moins en moins de logiciels utilisent les fichiers ini, sauf ceux qui sont multi-platforme.
Quelques remarques s'imposent... :-)
1. De *plus en plus* de logiciels retournent au .INI (et MS nous y encourage fortement) à cause de l'encombrement croissant de la registry qui commence à poser de sérieux problèmes de performances.
2. Les .INI ne doivent pas être stockés dans le répertoire de l'application mais dans un sous-répertoire de C:Documents and Settings<user>Application Data, habituellement, C:Documents and Settings<user>Application Data<nom_entreprise><nom_appli>. le chemin de ce répertoire s'obtient via l'API SHGetFolderPath et le flag CSIDL_APPDATA. En effet, il ne vous a pas échappé que par défaut, les répertoires C:Program Filesxxxx ne sont pas accessibles en écriture à l'utilisateur non admin et c'est très bien. Les infos de configuration de l'appli modifiables par l'utilisateur doivent donc être stockées ailleurs.
3. Pour utiliser le flag ci-dessus, il faut la version 4.71 de Comctl32.dll, Shell32.dll, et Shlwapi.dll (installées par IE 4et au-dessus).
4. [facultatif] Pour utiliser toutes les possibilités de cette API (tous les flags CSIDL_xxxxx), il faut la version 5.0 mini. Dans ce cas, sous Win9x, il faut que votre programme d'installation installe le package SHFolder que vous trouverez ici: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyIDjE02498-07E9-48F1-A5D6-DBFA18D37E0F . Ce package installe SHFolder.dll.
5. Le fait que ce répertoire soit spécifique à l'utilisateur vous dispense d'avoir à récupérer le nom de l'utilisateur. L'API vous retourne le bon répertoire pour l'utilisateur courant.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Bonjour,
Clive wrote:
2) Un problème avec la "personalisation" d'un fichier .ini est que
cela impose de démander le nom de l'utilisateur à chaque lancement,
sauf si on essaie de récuperer le nom de login. Cela devient
rapidement une vrai usine à gaz.
Je suis d'accord que "bricoler" dans la BdR peut donner des résultats
inattendus, mais l'utilsation de SaveSetting/GetSetting est très simpe
et, autant que je sache, très sûr. J'ai aussi l'impression que de
moins en moins de logiciels utilisent les fichiers ini, sauf ceux qui
sont multi-platforme.
Quelques remarques s'imposent... :-)
1. De *plus en plus* de logiciels retournent au .INI (et MS nous y
encourage fortement) à cause de l'encombrement croissant de la registry
qui commence à poser de sérieux problèmes de performances.
2. Les .INI ne doivent pas être stockés dans le répertoire de
l'application mais dans un sous-répertoire de C:Documents and
Settings<user>Application Data, habituellement, C:Documents and
Settings<user>Application Data<nom_entreprise><nom_appli>. le
chemin de ce répertoire s'obtient via l'API SHGetFolderPath et le flag
CSIDL_APPDATA. En effet, il ne vous a pas échappé que par défaut, les
répertoires C:Program Filesxxxx ne sont pas accessibles en écriture à
l'utilisateur non admin et c'est très bien. Les infos de configuration
de l'appli modifiables par l'utilisateur doivent donc être stockées
ailleurs.
3. Pour utiliser le flag ci-dessus, il faut la version 4.71 de
Comctl32.dll, Shell32.dll, et Shlwapi.dll (installées par IE 4et
au-dessus).
4. [facultatif] Pour utiliser toutes les possibilités de cette API (tous
les flags CSIDL_xxxxx), il faut la version 5.0 mini. Dans ce cas, sous
Win9x, il faut que votre programme d'installation installe le package
SHFolder que vous trouverez ici:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyIDjE02498-07E9-48F1-A5D6-DBFA18D37E0F .
Ce package installe SHFolder.dll.
5. Le fait que ce répertoire soit spécifique à l'utilisateur vous
dispense d'avoir à récupérer le nom de l'utilisateur. L'API vous
retourne le bon répertoire pour l'utilisateur courant.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
2) Un problème avec la "personalisation" d'un fichier .ini est que cela impose de démander le nom de l'utilisateur à chaque lancement, sauf si on essaie de récuperer le nom de login. Cela devient rapidement une vrai usine à gaz.
Je suis d'accord que "bricoler" dans la BdR peut donner des résultats inattendus, mais l'utilsation de SaveSetting/GetSetting est très simpe et, autant que je sache, très sûr. J'ai aussi l'impression que de moins en moins de logiciels utilisent les fichiers ini, sauf ceux qui sont multi-platforme.
Quelques remarques s'imposent... :-)
1. De *plus en plus* de logiciels retournent au .INI (et MS nous y encourage fortement) à cause de l'encombrement croissant de la registry qui commence à poser de sérieux problèmes de performances.
2. Les .INI ne doivent pas être stockés dans le répertoire de l'application mais dans un sous-répertoire de C:Documents and Settings<user>Application Data, habituellement, C:Documents and Settings<user>Application Data<nom_entreprise><nom_appli>. le chemin de ce répertoire s'obtient via l'API SHGetFolderPath et le flag CSIDL_APPDATA. En effet, il ne vous a pas échappé que par défaut, les répertoires C:Program Filesxxxx ne sont pas accessibles en écriture à l'utilisateur non admin et c'est très bien. Les infos de configuration de l'appli modifiables par l'utilisateur doivent donc être stockées ailleurs.
3. Pour utiliser le flag ci-dessus, il faut la version 4.71 de Comctl32.dll, Shell32.dll, et Shlwapi.dll (installées par IE 4et au-dessus).
4. [facultatif] Pour utiliser toutes les possibilités de cette API (tous les flags CSIDL_xxxxx), il faut la version 5.0 mini. Dans ce cas, sous Win9x, il faut que votre programme d'installation installe le package SHFolder que vous trouverez ici: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyIDjE02498-07E9-48F1-A5D6-DBFA18D37E0F . Ce package installe SHFolder.dll.
5. Le fait que ce répertoire soit spécifique à l'utilisateur vous dispense d'avoir à récupérer le nom de l'utilisateur. L'API vous retourne le bon répertoire pour l'utilisateur courant.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Clive
Merci Patrick pour ces précisions.
J'adopte pour l'avenir.
Des liens vers une classe qui gère tout cela avec la même facilté que Get/SaveSetting svp ???
A plus Clive
Merci Patrick pour ces précisions.
J'adopte pour l'avenir.
Des liens vers une classe qui gère tout cela avec la même facilté
que Get/SaveSetting svp ???
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Clive
Merci pour le lien Patrick.
Mais je cherchais plutôt une classe comme celui de vbaccelerator ici http://www.vbaccelerator.com/home/VB/Code/Libraries/Registry_and_Ini_Files/ Easy_Ini_File_Access/article.asp
Question subsidiaire... Doit-on utiliser les APIs style GetPrivateprofileString une fois qu'on a trouvé le bon folder pour l'ini file ? (Rappel: Les fonctions ...PrivateProfile... avaient un caveat comme ceci - "This function is provided only for compatibility with 16-bit Windows-based applications. Win32-based applications should store initialization information in the registry.")
Clive
Merci pour le lien Patrick.
Mais je cherchais plutôt une classe comme celui de vbaccelerator ici
http://www.vbaccelerator.com/home/VB/Code/Libraries/Registry_and_Ini_Files/ Easy_Ini_File_Access/article.asp
Question subsidiaire...
Doit-on utiliser les APIs style GetPrivateprofileString une fois qu'on
a trouvé le bon folder pour l'ini file ?
(Rappel: Les fonctions ...PrivateProfile... avaient un caveat comme
ceci - "This function is provided only for compatibility with 16-bit
Windows-based applications. Win32-based applications should store
initialization information in the registry.")
Mais je cherchais plutôt une classe comme celui de vbaccelerator ici http://www.vbaccelerator.com/home/VB/Code/Libraries/Registry_and_Ini_Files/ Easy_Ini_File_Access/article.asp
Question subsidiaire... Doit-on utiliser les APIs style GetPrivateprofileString une fois qu'on a trouvé le bon folder pour l'ini file ? (Rappel: Les fonctions ...PrivateProfile... avaient un caveat comme ceci - "This function is provided only for compatibility with 16-bit Windows-based applications. Win32-based applications should store initialization information in the registry.")
Clive
Patrick Philippot
Clive wrote:
Mais je cherchais plutôt une classe comme celui de vbaccelerator ici http://www.vbaccelerator.com/home/VB/Code/Libraries/Registry_and_Ini_Files/Easy_Ini_File_Access/article.asp
Question subsidiaire... Doit-on utiliser les APIs style GetPrivateprofileString une fois qu'on a trouvé le bon folder pour l'ini file ?
Une fois que le dossier dans lequel le .INI doit être stocké est défini, on procède comme d'habitude avec n'importe quel fonction / classe capable d'écrire dans un .INI.
Le code sur la page citée convient (quoique pas tellement objet), il faut juste remplacer App.Path par le résultat de l'appel à SHGetFolderPath.
(Rappel: Les fonctions ...PrivateProfile... avaient un caveat comme ceci - "This function is provided only for compatibility with 16-bit Windows-based applications. Win32-based applications should store initialization information in the registry.")
Eh bien, MS a changé d'avis entretemps. Itou en .Net : ce ne sont plus des .INI mais des .config (XML). Les infos ne vont plus dans la registry mais dans le dossier en question.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Clive wrote:
Mais je cherchais plutôt une classe comme celui de vbaccelerator ici
http://www.vbaccelerator.com/home/VB/Code/Libraries/Registry_and_Ini_Files/Easy_Ini_File_Access/article.asp
Question subsidiaire...
Doit-on utiliser les APIs style GetPrivateprofileString une fois qu'on
a trouvé le bon folder pour l'ini file ?
Une fois que le dossier dans lequel le .INI doit être stocké est défini,
on procède comme d'habitude avec n'importe quel fonction / classe
capable d'écrire dans un .INI.
Le code sur la page citée convient (quoique pas tellement objet), il
faut juste remplacer App.Path par le résultat de l'appel à
SHGetFolderPath.
(Rappel: Les fonctions ...PrivateProfile... avaient un caveat comme
ceci - "This function is provided only for compatibility with 16-bit
Windows-based applications. Win32-based applications should store
initialization information in the registry.")
Eh bien, MS a changé d'avis entretemps. Itou en .Net : ce ne sont plus
des .INI mais des .config (XML). Les infos ne vont plus dans la registry
mais dans le dossier en question.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Mais je cherchais plutôt une classe comme celui de vbaccelerator ici http://www.vbaccelerator.com/home/VB/Code/Libraries/Registry_and_Ini_Files/Easy_Ini_File_Access/article.asp
Question subsidiaire... Doit-on utiliser les APIs style GetPrivateprofileString une fois qu'on a trouvé le bon folder pour l'ini file ?
Une fois que le dossier dans lequel le .INI doit être stocké est défini, on procède comme d'habitude avec n'importe quel fonction / classe capable d'écrire dans un .INI.
Le code sur la page citée convient (quoique pas tellement objet), il faut juste remplacer App.Path par le résultat de l'appel à SHGetFolderPath.
(Rappel: Les fonctions ...PrivateProfile... avaient un caveat comme ceci - "This function is provided only for compatibility with 16-bit Windows-based applications. Win32-based applications should store initialization information in the registry.")
Eh bien, MS a changé d'avis entretemps. Itou en .Net : ce ne sont plus des .INI mais des .config (XML). Les infos ne vont plus dans la registry mais dans le dossier en question.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Jean-Marc
"Patrick Philippot" a écrit dans le message de news:Onf5$
Clive wrote: > Mais je cherchais plutôt une classe comme celui de vbaccelerator ici >
> > Question subsidiaire... > Doit-on utiliser les APIs style GetPrivateprofileString une fois qu'on > a trouvé le bon folder pour l'ini file ?
Une fois que le dossier dans lequel le .INI doit être stocké est défini, on procède comme d'habitude avec n'importe quel fonction / classe capable d'écrire dans un .INI.
Le code sur la page citée convient (quoique pas tellement objet), il faut juste remplacer App.Path par le résultat de l'appel à SHGetFolderPath.
> (Rappel: Les fonctions ...PrivateProfile... avaient un caveat comme > ceci - "This function is provided only for compatibility with 16-bit > Windows-based applications. Win32-based applications should store > initialization information in the registry.")
Eh bien, MS a changé d'avis entretemps. Itou en .Net : ce ne sont plus des .INI mais des .config (XML). Les infos ne vont plus dans la registry mais dans le dossier en question.
Hello,
je n'ai plus grand chose à ajouter, merci Patrick :-)
les fichiers de config en XML sont devenus de plus en plus utilisés, et pas seulement pour les applis VB. Les fichiers .ini quand à eux restent très répandus, en tout cas dans le monde professionnel et particulièrement le monde non Windows.
L'avenir est certainement au XML.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> a écrit dans le
message de news:Onf5$EweFHA.3712@TK2MSFTNGP09.phx.gbl...
Clive wrote:
> Mais je cherchais plutôt une classe comme celui de vbaccelerator ici
>
>
> Question subsidiaire...
> Doit-on utiliser les APIs style GetPrivateprofileString une fois qu'on
> a trouvé le bon folder pour l'ini file ?
Une fois que le dossier dans lequel le .INI doit être stocké est défini,
on procède comme d'habitude avec n'importe quel fonction / classe
capable d'écrire dans un .INI.
Le code sur la page citée convient (quoique pas tellement objet), il
faut juste remplacer App.Path par le résultat de l'appel à
SHGetFolderPath.
> (Rappel: Les fonctions ...PrivateProfile... avaient un caveat comme
> ceci - "This function is provided only for compatibility with 16-bit
> Windows-based applications. Win32-based applications should store
> initialization information in the registry.")
Eh bien, MS a changé d'avis entretemps. Itou en .Net : ce ne sont plus
des .INI mais des .config (XML). Les infos ne vont plus dans la registry
mais dans le dossier en question.
Hello,
je n'ai plus grand chose à ajouter, merci Patrick :-)
les fichiers de config en XML sont devenus de plus en
plus utilisés, et pas seulement pour les applis VB.
Les fichiers .ini quand à eux restent très répandus, en
tout cas dans le monde professionnel et particulièrement
le monde non Windows.
L'avenir est certainement au XML.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
> > Question subsidiaire... > Doit-on utiliser les APIs style GetPrivateprofileString une fois qu'on > a trouvé le bon folder pour l'ini file ?
Une fois que le dossier dans lequel le .INI doit être stocké est défini, on procède comme d'habitude avec n'importe quel fonction / classe capable d'écrire dans un .INI.
Le code sur la page citée convient (quoique pas tellement objet), il faut juste remplacer App.Path par le résultat de l'appel à SHGetFolderPath.
> (Rappel: Les fonctions ...PrivateProfile... avaient un caveat comme > ceci - "This function is provided only for compatibility with 16-bit > Windows-based applications. Win32-based applications should store > initialization information in the registry.")
Eh bien, MS a changé d'avis entretemps. Itou en .Net : ce ne sont plus des .INI mais des .config (XML). Les infos ne vont plus dans la registry mais dans le dossier en question.
Hello,
je n'ai plus grand chose à ajouter, merci Patrick :-)
les fichiers de config en XML sont devenus de plus en plus utilisés, et pas seulement pour les applis VB. Les fichiers .ini quand à eux restent très répandus, en tout cas dans le monde professionnel et particulièrement le monde non Windows.
L'avenir est certainement au XML.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
