Lucyberad
Messages postés414Date d'inscriptionmercredi 16 juin 2004StatutMembreDernière intervention26 juillet 2007
-
10 févr. 2006 à 12:38
Secondary117
Messages postés44Date d'inscriptionlundi 28 novembre 2011StatutMembreDernière intervention26 décembre 2013
-
18 avril 2013 à 19:41
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
Bonjour
bin oui et ça reste encore une des meilleures solution à mon avis.
Toutes les autres solutions que j'ai testées présentais plus d'inconvénients que d'avantages.
En plus j'ai développé des API autour de ces fichiers, et je ne vois pas l'intérêt de les ré-écrire, du moins dans l'immédiat.
JJDAI
AlexWebFrance
Messages postés2Date d'inscriptionmardi 26 février 2008StatutMembreDernière intervention 9 mars 2010 9 mars 2010 à 10:46
Il y a encore des applications qui tourne sur plusieurs langages et qui utilisent encore des ".INI" à tords ou à raison.
Juste pour dire que je dois faire une appli avec des fichiers de langues qui seront traduits par le client en fonction de ses besoins et que les fichiers ini reste encore le plus pratique pour ça, sauf si'il y a une solution que je ne connais pas !
cs_dugh
Messages postés9Date d'inscriptionlundi 14 avril 2003StatutMembreDernière intervention23 juillet 2009 23 juil. 2009 à 17:07
Merci Pym Corp pour ton petit module bien sympatique et pratique.
LeWolf
Messages postés31Date d'inscriptionmardi 14 août 2001StatutMembreDernière intervention29 décembre 2008 14 juin 2009 à 08:59
Merci
Et a moi ca va servir.
Car c'est vrai que la config dans .Net est très bien.
Mais les fichiers ini sont structuré donc pratique a lire, et pour le but n'est pas d'y stocker la configuration du programme. Mais des informations de copies de fichier pour la mise a jour d'un programme.
Le setup vérifaint les mises a jour fourni par .Net est trop long dans mon cas, et il ne vérifie pas tout.
darkmalcolm
Messages postés6Date d'inscriptionvendredi 18 août 2006StatutMembreDernière intervention25 juin 2012 9 sept. 2008 à 14:35
Merci pour cette petite source toujours util
Lucyberad
Messages postés414Date d'inscriptionmercredi 16 juin 2004StatutMembreDernière intervention26 juillet 20073 12 févr. 2006 à 14:29
ouais mais le ini c'est encore bien pour les configuration mais je me suis mis au xml car pour faire de la base de donnée c'est nikel, le ini est lui par contre limité en taille maximale.
OneHacker
Messages postés1447Date d'inscriptionjeudi 2 novembre 2000StatutMembreDernière intervention23 septembre 20072 11 févr. 2006 à 13:13
Il n'y pas besoin d'utiliser les DLL pour les fichiers INI est c'est vrai que le XML est mieux car plus simple et plus ordonné.
Lucyberad: Ce tu dis est vrai tant que l'on reste dans l'environnement dotNet. Pour ma part j'ai eu à dévlopper des applis qui doivent communiquer avec des mainframe (os2...) qui n'implémente pas encore XML, et les fichiers INI restent un solution viable dans dans ce contexte.
Il doit exister des parseurs XML en COBOL, mais leur usage n'est à priori pas encore généralisé.
Bref il y a des contexte ou il faut faire comniquer des syteme certes qui ont un peu de bouteille, avec des technologies du dernier cri, et donc l'interet d'utiliser encore les ficiers INI n'est pas completement null.
Un autre aspec qu'il ne faut pas négliger est que les même information en XLM génére un fichier beaucoup plus verbeux que des fichiers Ini et donc une taille plus iportante. Certes à l'heure du super ADSL c'est négligeable, mais il existe encore hélas beaucoup de systeme qui traine la pette et ou il faut gérer l'économie de quelques octets.
Et puis on change pas ses habitudes comme ça après 20 de pratique (non mais m'enfin, hahaha !!)
Lucyberad
Messages postés414Date d'inscriptionmercredi 16 juin 2004StatutMembreDernière intervention26 juillet 20073 11 févr. 2006 à 10:57
Pym corp => ha oui ^^ c'est dans les config du projet, je vien de voir une video du devdays 2005 qui montre comment on les utilise.
JJDai => les ini c'est que les vieux programmme qui n'utilise pas le framework (et ils sont nombreux) utilise encore du .ini
donc a par l'interet de les lire en dotnet (et c'est a chak programme donc je voi pas l'interet), puisque le programme est en .net autant utiliser les .config
Faudrait pas enterrer les fichiers INI trop vite, j'en ai dénombré quand même 570 sur mon disque C sous XP.
Ils ont quelques avantages qu'il ne faut pas négliger (Lisibilité , simplicité, ...)
D'Ailleurs un truc pas mal serait de faire un convertisseur INI->XML, dans l'autre sens je ne suis pas sur que ce soit possible si l'arborescence est rop profonde.
Ce que je trouve domage c'est qu'il faille déclarer des API, et à moins de refaire un parseur de fichier INI, il n'y a pas le choix semble-t-il.
Pym Corp
Messages postés166Date d'inscriptionjeudi 9 décembre 2004StatutMembreDernière intervention18 novembre 2007 11 févr. 2006 à 07:29
Lucyberad Je sais pas si t'es au courant, mais c'est intégré dans dotnet 2 la gestion du xml automatique pour les paramètres d'applications (le rêve quoi)
Lucyberad
Messages postés414Date d'inscriptionmercredi 16 juin 2004StatutMembreDernière intervention26 juillet 20073 10 févr. 2006 à 17:47
personnelement je choisis tout simplement du xml, c'est plus simple que le ini et c'est moins bardelique a faire fonctionner que les app.config
Pym Corp
Messages postés166Date d'inscriptionjeudi 9 décembre 2004StatutMembreDernière intervention18 novembre 2007 10 févr. 2006 à 14:23
Ouai mais c'est vrai que de nos jours, les ini ça sert à rien (et surtout depuis dotnet 2)
Ou si tu veux rester dans les ini, beaucoup plus court et à mettre dans un module :
Module modINI
Dim fichier As String = IO.Path.ChangeExtension(Application.ExecutablePath, ".ini")
#Region "Lire INI"
Private Declare Function GetPrivateProfileString Lib "kernel32" Alias "GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal lpKeyName As String, ByVal lpDefault As String, ByVal lpReturnedString As System.Text.StringBuilder, ByVal nSize As Integer, ByVal lpFileName As String) As Integer
Function lireINI(ByVal Entete As String, ByVal Variable As String) As String
Dim defval As String
Try
Dim StrBuild As New System.Text.StringBuilder(32768)
Dim Ret As Integer = GetPrivateProfileString(Entete, Variable, defval, StrBuild, 32768, Fichier)
Return StrBuild.ToString
Catch
Return defval
End Try
End Function
#End Region
#Region "Ecrire INI"
Private Declare Function WritePrivateProfileString Lib "kernel32" Alias "WritePrivateProfileStringA" (ByVal lpApplicationName As String, ByVal lpKeyName As String, ByVal lpString As String, ByVal lpFileName As String) As Integer
Function ecrireINI(ByVal entete As String, ByVal variable As String, ByVal valeur As String)
WritePrivateProfileString(entete, variable, valeur, fichier)
End Function
#End Region
End Module
Lucyberad
Messages postés414Date d'inscriptionmercredi 16 juin 2004StatutMembreDernière intervention26 juillet 20073 10 févr. 2006 à 12:38
utilise les app.config ou encore mieux, moi j'utilise du xml.
neamoins la source est pas mal pour les .ini
c'est juste que c'est specifique a vb6 et non vb.net.
18 avril 2013 à 19:41
15 févr. 2012 à 12:55
9 mars 2010 à 21:19
bin oui et ça reste encore une des meilleures solution à mon avis.
Toutes les autres solutions que j'ai testées présentais plus d'inconvénients que d'avantages.
En plus j'ai développé des API autour de ces fichiers, et je ne vois pas l'intérêt de les ré-écrire, du moins dans l'immédiat.
JJDAI
9 mars 2010 à 10:46
31 août 2009 à 09:41
23 juil. 2009 à 17:07
14 juin 2009 à 08:59
Et a moi ca va servir.
Car c'est vrai que la config dans .Net est très bien.
Mais les fichiers ini sont structuré donc pratique a lire, et pour le but n'est pas d'y stocker la configuration du programme. Mais des informations de copies de fichier pour la mise a jour d'un programme.
Le setup vérifaint les mises a jour fourni par .Net est trop long dans mon cas, et il ne vérifie pas tout.
9 sept. 2008 à 14:35
12 févr. 2006 à 14:29
11 févr. 2006 à 13:13
Bonne continuation !
Redman
11 févr. 2006 à 11:57
Il doit exister des parseurs XML en COBOL, mais leur usage n'est à priori pas encore généralisé.
Bref il y a des contexte ou il faut faire comniquer des syteme certes qui ont un peu de bouteille, avec des technologies du dernier cri, et donc l'interet d'utiliser encore les ficiers INI n'est pas completement null.
Un autre aspec qu'il ne faut pas négliger est que les même information en XLM génére un fichier beaucoup plus verbeux que des fichiers Ini et donc une taille plus iportante. Certes à l'heure du super ADSL c'est négligeable, mais il existe encore hélas beaucoup de systeme qui traine la pette et ou il faut gérer l'économie de quelques octets.
Et puis on change pas ses habitudes comme ça après 20 de pratique (non mais m'enfin, hahaha !!)
11 févr. 2006 à 10:57
JJDai => les ini c'est que les vieux programmme qui n'utilise pas le framework (et ils sont nombreux) utilise encore du .ini
donc a par l'interet de les lire en dotnet (et c'est a chak programme donc je voi pas l'interet), puisque le programme est en .net autant utiliser les .config
en vb6 les ini sont utilse mais pas en .net
11 févr. 2006 à 10:50
Ils ont quelques avantages qu'il ne faut pas négliger (Lisibilité , simplicité, ...)
D'Ailleurs un truc pas mal serait de faire un convertisseur INI->XML, dans l'autre sens je ne suis pas sur que ce soit possible si l'arborescence est rop profonde.
Ce que je trouve domage c'est qu'il faille déclarer des API, et à moins de refaire un parseur de fichier INI, il n'y a pas le choix semble-t-il.
11 févr. 2006 à 07:29
10 févr. 2006 à 17:47
10 févr. 2006 à 14:23
Ou si tu veux rester dans les ini, beaucoup plus court et à mettre dans un module :
Module modINI
Dim fichier As String = IO.Path.ChangeExtension(Application.ExecutablePath, ".ini")
#Region "Lire INI"
Private Declare Function GetPrivateProfileString Lib "kernel32" Alias "GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal lpKeyName As String, ByVal lpDefault As String, ByVal lpReturnedString As System.Text.StringBuilder, ByVal nSize As Integer, ByVal lpFileName As String) As Integer
Function lireINI(ByVal Entete As String, ByVal Variable As String) As String
Dim defval As String
Try
Dim StrBuild As New System.Text.StringBuilder(32768)
Dim Ret As Integer = GetPrivateProfileString(Entete, Variable, defval, StrBuild, 32768, Fichier)
Return StrBuild.ToString
Catch
Return defval
End Try
End Function
#End Region
#Region "Ecrire INI"
Private Declare Function WritePrivateProfileString Lib "kernel32" Alias "WritePrivateProfileStringA" (ByVal lpApplicationName As String, ByVal lpKeyName As String, ByVal lpString As String, ByVal lpFileName As String) As Integer
Function ecrireINI(ByVal entete As String, ByVal variable As String, ByVal valeur As String)
WritePrivateProfileString(entete, variable, valeur, fichier)
End Function
#End Region
End Module
10 févr. 2006 à 12:38
neamoins la source est pas mal pour les .ini
c'est juste que c'est specifique a vb6 et non vb.net.
(ps: ne le prend pas mal)