Remarqué aujourd’hui.
Et surement déjà signalé, mais sait-on jamais …
Lorsqu’un fichier xml est chargé en mémoire par GD, et qu’il est ensuite déchargé, il écrase le fichier physique du disque dur.
Ce qui veut dire que si on a fait des corrections dans ce fichier physique alors que GD était encore ouvert, tout sera perdu à la fermeture du logiciel.
Cela signifie aussi que, pour que GD prenne en compte les changements dans un fichier xml modifié avec le bloc-notes, ces modifications doivent être faites lorsque GD est fermé.
Sinon, il les ignore superbement, et les écrase à sa fermeture.
C’est un comportement normal ?
Ou est-ce la conséquence logique de la commande “décharger fichier xml” de l’éditeur d’évènements ?
C’est, je crois, le comportement logique de l’action de déchargement.
Si tu veux pouvoir modifier ton fichier xml pendant l’exécution, tu n’as qu’à pas mettre l’action Charger en mémoire et de déchargement. La lecture d’un xml peut fonctionner sans, mais sera plus longue sur des gros fichiers.
C’est voulu.
Par défaut, si tu charge pas le fichier en mémoire, GD l’ouvre et l’enregistre à chaque modification/accès.
Si tu le charge en mémoire, il ne le sauvegarde que quand tu le décharge de la mémoire. Mais tu gagne énormément en vitesse de lecture/écriture sur des gros fichiers. ( Et à ce moment, il sauvegarde ce qu’il a en mémoire donc, soit ce que tu avais à l’époque de l’ouverture + les modifications ).
Parce qu’il y a quand même un binz, c’est quand il s’agit d’un fichier de dialogues.
Etant donné qu’il doit être lu et seulement lu, l’utilisateur ne pense pas que toutes ses modif seront écrasées à la sortie de GD.
Ca peut faire de sacrés dégats.
Et ça ralentit le process de création des dialogues, puisqu’il faut modifier les dialogues, lancer GD, tester, fermer GD, modifier les dialogues, ouvrir GD, tester, fermer GD, modifier les dialogues, lancer GD, etc.
Impossible de faire des corrections en “temps réel”.
L’action “Fermer un fichier chargé en mémoire” précise bien que :
Cette action ferme le fichier XML chargé précédemment en mémoire, en enregistrant les modifications apportées à celui ci.
Je vais modifier la description de l’action de chargement en mémoire pour bien spécifier qu’il faut décharger le fichier ensuite.
Il suffit soit :
-De pas charger le fichier en mémoire.
-Si tu le charge en mémoire, alors tu t’assure de le décharger, aussi vite que possible.
Pas besoin de fermer GD si tu décharge bien le fichier, je pense que le problème vient de là.
Actuellement, le fichier est en effet tout le temps réenregistré à la fermeture.
J’ai modifié les actions pour que le fichier ne soit réenregistré que si il a subi des modifications. ( J’avais prévu ça à la base, mais oublié d’activer l’option en quelque sorte dans le code )
Tu pourra donc charger un fichier en mémoire, le lire, et le refermer sans qu’il soit écrasé.
).