Modifications DFM ignorées

Bonjour,

Après deux jours de galère pendant lesquelles j'ai parcouru le net à la recherche d'une solution, je me tourne vers un forum où quelqu'un aura peut-être rencontré ce problème.

J'ai hérité d'un projet développé sous Borland C++ Builder 2006. Depuis un mois je faisais des corrections d'ordre logique, sans toucher à l'IHM, et tout allait bien. Pour un nouveau besoin j'ai dû ajouter une image sur une form, mais à l'exécution celle-ci ne s'affiche pas. Ayant tout essayé pour la faire apparaitre, j'ai fini par modifier des composants existants, du genre bouger un bouton, etc... Là encore, lorsque je recompile ou reconstruis l'appli, c'est l'ancienne version de l'IHM qui est reprise. Je ne comprends plus !!! Et si, à l'exécution, mon code fait référence à un des objets nouvellement insérés, j'ai droit à un EAccessError. :?

J'ai essayé de supprimer les .OBJ, au cas où... Ils sont bien regénérés à la compil, mais rien ne bouge dans l'IHM.

Est-ce que quelqu'un sait à quel moment sont utilisées les DFM ? J'ai l'impression que c'est lors de la phase de link, mais est-ce que des fichiers intermédiaires sont générés, que je pourrais purger ?

Merci de votre aide, je n'en peux plus et mon projet prend du retard... :cry:

PS: l'install de Borland C++ en elle-même fonctionne: j'ai créé un nouveau projet et modifié des données de l'IHM, mes modifs sont prises en compte.

Vérifie si tu n'as pas plusieurs fois le fichier DFM dans plusieurs répertoires
Un collègue a eu le même problème, plusieurs fois le fichier DFM dans les sources, conséquence la ressource incorporée dans l'exe restait une vieille DFM et les nouveaux composants restaient à NULL, tes VA en 00000000

le DFM Texte est transformé en une ressource binaire incluse dans l'exe, il n'y aucun contrôle dessus !
Lorsque tu fais un new, cela va implicitement chercher une ressource ayant le nom de la classe, cela charge ce binaire qui instancie dynamiquement tous les objets (ça c'est du code Delphi)

Merci le troll (jolie photo, tu es bien mignon),
malheureusement c'était le premier truc auquel j'avais pensé, et apparemment le problème ne vient pas de là: j'ai supprimé ou renommé toute copie existante de mes DFM, et même supprimé les copies de sauvegarde faites par Borland à chaque modification enregistrée.

Je n'oublie pas cette hypothèse, car malgré tout l'erreur est humaine, et comme je ne suis pas un bot...

Merci pour l'info de l'intégration de la dfm dans l'exe, je n'aurais pas cru que ça pouvait être aussi "simple".

Merci, tu as remarqué mon joli teint et ma peau douce :mouarf:

Ah, tu n'as pas de doublon, c'est plus génant !

Le Fichier DFM est souvent stocke en Texte, comme on le voit en faisant CTRL+F12
Attention, il y a deux options, "Voir en Texte" juste affichage et "DFM Texte" pour le stockage
Si tu veux comprendre le format binaire d'une DFM, j'en ai fait une rapide etude dans .dfm corrompu en XE

Lorsque mon collègue a eu le même problème que toi en C++Builder 2007, pour vérifier, je lui faisais recherche le nom de la classe dans l'exe via UltraEdit

Lorsque tu ajoute un nouveau button, tu dois voir nom apparaître dans l'exe, en 2006, c'est facile a trouver car ANSI
Cela peut être un moyen pour toi de détecter l'exactitude de la ressource !

Ah, aussi, le problème était avec un héritage de fenêtre, bon, personnellement, je n'aime pas l'héritage de DFM, mais je dois suivre la méthode de développement existante !
Je n'ai jamais trop étudié comme cela fonctionne exactement pour les DFM hérités, je crois que récursivement en partant de la ressource ancêtre, il charge chaque ressource jusqu'à la classe finale, ... tu imagines qu'une mauvaise DFM dans l'héritage peut tout casser !



En XE2, je n'ai pas encore regardé ce que cela donnait en binaire, je suppose que tout est doublé à cause de l'UNICODE, la recherche de chaine sera moins aisée !

Tient le sujet Problème de Compilation avec Delphi 2009 semble très proche du tient mais en Delphi !

J'ai ouvert une de mes DFM qui pose problème (c'est le cas de toutes celles de mon projet à priori) dans Notepad, pas de problème elle est bien lisible, et mes modifs apparaissent.
J'ai lancé une recherche de *.dfm, j'en ai d'autres qui portent son nom mais dans d'autres projets, rien à voir (en même temps son nom est FMain.dfm, donc pas étonnant qu'elle ne soit pas seule avec ce nom). Une autre DFM qui me pose aussi problème n'a pas d'homonyme.

Un collègue m'a suggéré de renommer FMain et de recompiler, on s'affranchit donc de tout problème de Nom de form; Même problème à la sortie.

Ce que je ne comprends pas, c'est comment Borland peut ressortir des anciennes infos sur la dfm, si aucun fichier n'existe; et ce même après un redémarrage de l'IDE ! Il y a forcément des fichiers quelque part, à moins qu'il ne récupère les infos de la DFM dans l'ancien.EXE avant de le remplacer, mais ça devient carrèment vicieux là....

Effectivement le problème que tu me cites avec Delphi est très [trop] ressemblant !
En tout cas merci pour ton aide, même si je suis toujours bloqué je me dis que d'autres ont déjà eu le problème, bizarrement ça me rassure...

Et quand tu fais une modification à la fenêtre, que tu sauvegarde, tu ferme l'IDE et tu le relance, les modifications sont toujours là ou pas (sans même parler de compilation) ?

Toutes les modifications que je peux faire sur l'IHM sont conservées. Simplement, elles ne sont pas mises dans l'exécutable.
Si un gars de chez Borland/Embarcadero passe par là, pourrait-il me dire d'où Builder me ressort la vieille version de mon IHM ???

Même si je ne fais que modifier un objet existant (bouger un bouton par exemple), cette modif n'est pas prise en compte; c'est donc l'intégralité du fichier DFM qui est ignorée.

Dans le doute, je suis reparti d'une vieille version de ma dfm, mais là encore les modifs ne sont pas portée à la compil. Je vais contacter le support Embarcadero, mais j'ai peur qu'ils me disent que la version de Builder n'est plus supportée, et de passer à une nouvelle version... Ce qui n'est pas envisageable.

pas de fichier .pch ou bcc32pch qui traine ?
tu as bien fait "nettoyer" dans les options du projet avant de le reconstruire ? (enfin, si ça existe sur bcb 2006 car c'est une des rares versions sur laquelle on a jamais travaillé ici)
Regarde dans le fichier du projet (.cbproj, c'est du xml) si les références au fichier dfm sont bien les bonnes (genre les lignes
<FormResources Include="Tfentoto.dfm" />
et
<Form>fentoto.dfm</Form>
)
sinon, tente en créant un nouveau répertoire, en déplaçant uniquement les fichiers sources dedans (*.cpp/*.h/*.dfm/*.rc)et en recréant le projet de zéro. C'est rapide à faire et souvent necessaire dans le cas de migration d'une version à l'autre de c++ Builder pour repartir bien proprement (je finis même par les modifier uniquement à la main ;))

Merci pour ces suggestions; non je n'ai aucun .pch ou bcc32pch dans mon répertoire de projet, et l'option "nettoyer" semble absente de cette version de Builder.

J'ai eu une réponse du support Embarcadero, qui me dit d'aller me faire voir, je n'ai pas de contrat de support, en plus Borland 2006 n'est plus supporté. Ils m'ont quand même confirmé ce qu'avait dit ShaiLeTroll, à savoir que les DFM sont directement insérées dans le .exe

Du coup je ne comprends toujours pas ce qui se passe. J'ai repris une vieille version de mon projet sur laquelle je n'ai pas ce problème. Je vais repartir de là et y remettre mes nouveaux fichiers, en espérant que ça passe ainsi. J'ai déjà perdu trop de temps sur ça, donc on ne va pas faire dans la dentelle...

Bonjour,

J'ai trouvé la réponse à mon problème, donc je viens la poster au cas où quelqu'un aurait un jour le même souci, et par respect pour ceux qui se sont intéressés à mes déboires: En fait nous utilisons Multilizer, pour traduire notre appli. Et visiblement, lorsque l'on touche à l'IHM, il faut repasser l'appli à la moulinette de Multilizer pour qu'il analyse ce qu'il y a de neuf, et l'ajoute dans l'exe en version multilangues.

Ah, petit cachotier :mouarf:
C'était bien la seul phase qui n'était pas automatisé avec FinalBuilder, il fallait que le développeur pense à regénérer les fichiers LNG au moment de "CheckInner" lles sources sur JEDI VCS pour qu'il soit à jour lors de la génération de la version !

Effectivement, il conserve les chaines des DFM à traduire de la version précédente, j'ai oublié, il associe la chaine ou une propriété d'un Control pour les DFM ?

Pour les chaines libres, tu ne changes pas la chaine de Multilizer, il peut ne pas trouver la traduction donc laisse la langue par défaut
D'ailleurs, pense à nettoyer, tu as des chaines qui finissent par ne plus être utilisé, je ne sais plus si le rebuild les éliminent ?

Dans mon ancienne boîte, on avait Multilizer en D6, on l'a abandonné en D7 au profit d'un système maison en fichier ini bien plus simple à manipuler !
Même si Multilizer est plus simple que l'outil intégré à Delphi

J'avais même écrit un programme qui remplaçait les Translate MZ par notre propre fonction Translate qui avait besoin d'un ID de chaine, la traduction par ce système était 1000 fois plus rapide, mais nécessitait une rigueur des devs pour la numérotation, heureusement les fichiers de langue était Locké par JEDI donc seul un développeur pouvait modifier par de problème de merge comme avec SubVersion\Tortoise !