Rien ne lui interdit de le mettre en fichier caché et/ou read only.
Ou, comme je l'écrivais précédemment de passer par la BDR. Dans le développement Windows, les fichiers INI ne sont conservés que pour des raison de rétro-compatibilité.
Un autre cas d'utilisation est le cas où l'application est destinée à être multi-plateforme dans l'entreprise.
Je vais un peu développer.
windev stocke les différents paramètres mémorisés (emplacement des fenêtre, valeur d'un champ mémorisé ...) d'une application dans un hive de la BDR.
2 cas se produisent
Mode Test : HKEY_CURRENT_USER\SOFTWARE\PC SOFT\windev\<N°VersionWindev>\ModeTest\<Nom du projet>, <N°VersionWindev> correspond à la version de windev utilisée pour le développement du projet.
Mode Production : HKEY_CURRENT_USER\Software\<Société>\<Nom du projet>, <Société> correspond à la société indiquée lors de la création de l'exécutable. Si ce nom n'est pas renseigné, <Société> correspond à "Applications windev"
Il est inutile de mémoriser ces chemins, on peut les récupérer grâce à :
Code (Windev):
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
(piRegistre)
Pour les paramètres persos, e.g. Langue utilisée, extension par défaut, données de connexion ... windev met à notre disposition 2 fonctions
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
et
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
. Pour se passer du fichier INI, ce sont ces fonctions que nous allons utiliser.
Initialisation du projet
Code (Windev):
gsLangue estchaine
gsExtension estchaine
SIPAS InitialiserParamètres()ALORS
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
("Erreur lors de la lecture des paramètres",
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
()) FIN
Jusque là pas de différences avec l'utilisation d'un fichier INI.
La différence va se faire là :
Code (Windev):
FONCTION InitialiserParamètres():booléen //On récupère le hive dans lequel sont stockés les paramètres d'initialisation
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
(paramRegistre,
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
("%1\Paramètres",
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
(piRegistre)))
//On récupère les paramètres d'initialisation //Si c'est la première utilisation ou si un des deux paramètres n'a pas été sauvegerdé, les variable prendront les valeur "FR" et ".TXT" sinon elle prendront la valeur des clés "Langues" et "ExtensionDéfaut"
gsLangue=
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
("Langue","FR")
gsExtension=
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
("ExtensionDéfaut",".TXT")
//On remet l'emplacement des paramètre à sa valeur initiale pour que windev puisse utiliser les valeurs d'interface
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
(paramRegistre,
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens!
Merci beaucoup pour vos aides, je vais vous exposer exactement mon idée/problème.
J'ai créer un anti-recul pour un jeu vidéo (Apex), le script est utilisable avec le logiciel AutoHotKey (logiciel de macros), ce script est lu grâce a un fichier de configuration (.ini) et un fichier (.ahk identique au fichier .txt) qui est le script en lui même.
Je souhaiterais le commercialiser, mais pour cela, il faut que le script ne soit pas en lecture/écriture.
L’utilisateur peux changer les paramètres du fichier (.ini) depuis l'application mais ne doit pas pouvoir physiquement atteindre le fichier et en faire ce qu'il veux.
De plus l'utilisateur doit pouvoir exécuter le logiciel (.exe) et le script (.ahk) sans qu'il n'ai accès en direct à quoi que ce soit, que ça soit juste utilisable sans avoir les "sources".
Je ne sais pas si j'ai ai été plus clair, merci à vous
Donc le fichier INI est nécessaire à l'exécution du programme tiers.
Qu'à cela ne tienne, on va le créer au moment de l'utilisation, grâces aux variable globale que nous avons récupérées.
Dans le code de fermeture du projet, il suffira de faire l'opération inverse (récupération des valeurs de l'INI dans les variables globales puis sauvegarde dans la BDR) et à l'issue supprimer le fichier INI.
