[R] Quoi de mieux qu'un ini ?

[Iste]

Salutations,

Dans l'un de mes script, je note de nombreuses information dans un fichier sans extention, et les fonctions liées a la lecture et l'ecriture d'ini d'autoit.
Ca marche tres bien, c'est super, mais l'autre jour, je suis tombé sur ce topic :
http://autoitscript.fr/forum/viewtopic. ... ini#p14044

Et comme je risque de rapidement depasser les 64ko, je suis allé voir du coté du xml, mais apres lecture de :
http://autoitscript.fr/forum/viewtopic.php?f=3&t=2360
Cela me parrait un peu compliqué.

D'ou mes questions :

-Suis-je limité par le format ini avec l'utilisation que je fait des fonctions ?

-Si oui, comment remplacer simplement ces fonction ?
(quel serait les equivalent des fonctions pour le xml, ou que puis-je utiliser d'autre)

Merci d'avance

[Tlem]

Si vous comptez utiliser un fichier ini au delà des 64Ko, il vaut mieux dans ce cas passer par une base de donnée.

http://www.autoitscript.com/forum/index ... t&p=143788

[Iste]

heu, j'ai dis que je trouvais le xml trop compliqué, c'etait pour qu'on me conseil plus simple ^^' de plus, je m'y connais pas trop, mais une base de donné ca se trouve pas sur le net ? (a l'aide d'un server et tout)

Si j'avais utilisé les fonction de lecture/ecriture des ini, c'etait pour faire simple.
car FileReadLine() était un peu trop compliqué a utilisé (dans le sens ou il j'aurai du creer des fonction pour ecrir correctement les ligne au bon endroit)

Donc bon, je vais quand meme jetter un coup d'oeil sur mysql.au3, car je refuse aucune aide !

[Tlem]

Ben ... Sinon pour le XML, c'est ici :
http://www.autoitscript.com/forum/index ... opic=19848

[Voodoo]

Vous avez aussi _sqlite qui est la même chose que Mysql mais en local. Les fonctions sont intégrées dans autoit3. Mais il faut connaitre le langage sql et avoir quelques connaissances en base de donnée.

Dans votre cas, si vous préférez mettre en avant la facilité de conception du programme plutôt que son efficacité, alors pourquoi pas un simple fichier *.txt ?
En créant votre propre format de structure par exemple Nom|genre|age:

Code : Tout sélectionner

Toto|homme|25
Titi|homme|63
 

Et vous faite vos fonctions pour traiter le fichier à coup de Fileread et de stringsplit.

[Iste]

Je n'ai pas utilisé Fileread() car dans chaque section j'ai un nombre indefinit de key, donc c'etait pas trop pratique
M'enfin, je vais regarder tout ca, je pense que toutes les solutions alternatives ont été citées, merci donc de vos reponses, je vais regarder tout ca pour voir ce qui me va le mieux !

[TurT]

Peut-on a l'aide d'une base de donnée rendre l'affichage de l'interface dynamique?

Je m'explique:
créer autant de Checkbox qu'il y a d'entrée dans une table de la base de donnée, pour des logiciels par exemple.

Merci.

[Voodoo]

Il n'y a pas de corrélation entre l'interface dynamique et les bases de données.

Si vous voulez poser d'autre question sur l'interface dynamique commencer un nouveau post !

[Tlem]

Pour l'historique et les futur recherche, il est possible d'utiliser les UDF's de ce post pour passer outre la limitation des 64Ko.
http://www.autoitscript.com/forum/index ... t&p=371817

[jl56]

Bonjour à tous

Je post ici car je dois gérer un fichier qui approchera les 64 k

le system de gestion des *..ini me semble très facile et à ma portée technique

la limite de 64 k m'inquiète si je devais la dépasser

apres quelques recherches ,sur mon pc , des *.ini, j'ai trouvé plein de fichier > à 64 k
certain de programme microsoft
ex corperfmonsymbols.ini de [blink]1473 ko[/blink]
dans C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727


et celui de OrganizeIncludes4.3.au3
avec includes.ini à 110k

en regardant dans le fichier au3 il n'y a pas de fonction particulière pour la gestion des ini
je l'ai même testé en rajoutant des key et value sans probléme

Savez vous la limite réel pour la gestion d'un ini par autoit v3.3

Merci de vos réponses

A+ JL56

[Iste]

j'ai testé, et sous winXP32, les fonction qui lisent des .ini ne lisent que les 64 premier kilo octe.
Si t'es sous vista ou seven je sais pas, mais le mieux reste d'utiliser les fonction indépendantent de windows.
Sinon, avoir des gros ini c'est possible, car peut etre que les programme en question on leur propre gestion des .ini (comme mes programme autoit le font maintenant )

Donc voila, fait des test aprofondi pour verifier que ca marche pas, sinon béh, utilise quand meme les autre fonction, au cas ou, car ca serait bete qu'un jour tout bug a cause de ca

bonne chance!

[Tlem]

Il me semble bien avoir lu quelque part que les dev de AutoIt allais ré-écrire les fonctions de gestion des fichiers .ini pour passer outre la limite des 32k ou 64k.
Ceci devrait peut être fait dans la prochaine version de AutoIt (a vérifier).

Edit :
J'ai retrouvé ça ici : http://www.autoitscript.com/trac/autoit/ticket/15

Il y à même une prévision de ré-écrire la fonction FileReadLine() pour enlever la limite de 64K du buffer.
http://www.autoitscript.com/trac/autoit/ticket/682

[jl56]

Bonjour iste

Merci de ta réponse tres rapide

je suis en xppro 32 bits

Code : Tout sélectionner

; This is the INI file we will write to.  It will be created on the Desktop.
; renommer le fichier includes.ini en test.ini


$sIni = "C:\Program Files\AutoIt3\SciTE\OrganizeIncludes\Test.ini"

; Demonstrate creating a new section using a string as input.
$sData = "Key1=Value1" & @LF & "Key2=Value2" & @LF & "Key3=Value3"
IniWriteSection($sIni, "Section4", $sData)

; Demonstrate creating a new section using an array as input.
$aData1 = IniReadSection($sIni, "Section1") ; Read in what we just wrote above.
For $i = 1 To UBound($aData1) - 1
    $aData1[$i][1] &= "-" & $i  ; Change the data some
Next

IniWriteSection($sIni, "Section2", "cle test de jl56=test de lecture d'un fichier ini de 110k") ; Write to a new section.

; Demonstrate creating an array manually and using it as input.
Dim $aData2[3][2] = [ [ "FirstKey", "FirstValue" ], [ "SecondKey", "SecondValue" ], [ "ThirdKey", "ThirdValue" ] ]
; Since the array we made starts at element 0, we need to tell IniWriteSection() to start writing from element 0.
IniWriteSection($sIni, "Section3", $aData2, 0)
IniDelete($sIni, "Section3")

$var = IniReadSection("C:\Program Files\AutoIt3\SciTE\OrganizeIncludes\Test.ini", "section2")
If @error Then 
    MsgBox(4096, "", "Error occurred, probably no INI file.")
Else
    For $i = 1 To $var[0][0]
        MsgBox(4096, "", "Key: " & $var[$i][0] & @CRLF & "Value: " & $var[$i][1])
    Next
EndIf

dans ce code la création de section supplémentaire et la lecture fonctionne !!

STP quel solution as tu adopté

Merci

A+ JL56

[Tlem]

Voici ce qui est écrit dans la documentation au sujet des fonctions IniReadSection et IniReadSectionNames :

Only the first 32767 chars are taken in account in an section due to Win9x compatibility.

[jl56]

Bonjour Tlem

Merci pour ta réponse

comme tu vois dans le code que j'ai posté j'ai pu écrire et lire un fichier ini de 110k
pour l'instant cela suffit
et si effectivement les dev prévoient de faire mieux merci à eux

Je vais pouvoir continuer mon script avec un .ini

Merci à tous

A+ JL56

[Iste]

Le developement de ton script ne pose pas probleme
Tu pourras a tout moment changer tres facilement les fonction inixx() de base pas des UDF.
Donc si ca marche pour le moment, vas-y

La ou ca poserait probleme, c'est si tu compile et distribu ton script a d'autre, car si ca bloque, ben ca sera galere

Pour ma part, j'utilise des variantes des fonction donné dans le lien de tlem (j'ai uassi essayé avec l'UDF qui remplace les ini par des bdd, mais bof...)

[jl56]

Bonjour Tlem

Merci pour ta deuxième réponses

Effectivement la taille d'une section ne peut dépasser 32767 octets

dans les sections que je prévois
elles oscilleront entre 600 et 800 octets
mais j'ai limité à 100 sections d'ou mon inquiétude au dépassement de 64k de l'ini
800*100 = 80000 octet soit 78,25 ko max

Bonne nuit

A+ JL56

[Tlem]

A première vue, cette fameuse limitation des 32K ne concerne pas les fonctions IniRead, IniWrite, IniDelete, IniRenameSection et IniWriteSection mais seulement les fonctions IniReadSection et IniReadSectionNames.

Donc il semble que tant que vous n'utilisez pas ces fonctions, ou que vos section ne dépasse pas les 32k, il n'y à rien à craindre.

Edit: Coiffé sur le poteau.
Mais je laisse ma réponse.