| Posté le 31 décembre 2025 - 16:14 |
Bonjour à tous,
Depuis quelques année, nous avons la possibilité d'enregistrer nos objets (classes, collections de procédures, fenêtres, états...) au format texte.
Pour de nombreuses raisons, dont pour certains, l'analyse (semi-automatiques) des sources, la documentation..., Nous avons gagné en transparence. Bravo PC Soft, si nous faisons gentiment l'impasse sur le format (space indentation) et les internals properties  !
Maintenant que le débat autour de l'abonnement enfle, certains pensent peut-être avoir besoin de régresser leurs sources vers une version 28 ?
Alors la 5ème ligne de ces fichiers texte devrait être intéressante car elle mentionne la version utilisé.
major_version : 28
Devrais permettre d'ouvrir votre élément en Windev 28 ?
Que nenni !
Quelque part, dans ce fichier "ouvert", est caché la vraie version qui a servie à la dernière modification de votre fichier!
Par contre, même si vous avez créé votre "objet" avec un V2026, si vous indiquez major_version : 28, Windev détectera la version 28 et vous proposera une monté en version V2026 alors qu'en réalité, c'est bien déjà un fichier en version 2026...
Bref, vous pouvez monter mais pas descendre.
Descendre est certainement trop "compliqué" et surtout couteux pour PC Soft.
Note: j'en profite pour m'interroger sur une format texte avec une structure non JSON, non TOON, non YAML. Un bon vieux fichier indenté avec des espaces (un clin d'oeil à python ?) et des portions non lisibles (internal_properties, code, type_code...)
Bref...
--
La complexité d'une solution doit être adaptée à la complexité du problème qu'elle essaye de résoudre. |
| |
| |
|