Discussion :

[geek12]

Bonjour à tous,

Je développe une application sous Embarcadero C++ Builder en utilisant des boutons de type TspeedButton. Quand je lance mon application dans l'éditeur tout ce passe bien. Par contre en dehors de l'éditeur, au lancement de l'application les bouttons s'affichent mais l'images de fond ne s'affichent pas. J'ai juste un carré blanc qui s'affiche en image de fond de chaque bouton. Avez-vous une idée de la cause de ce type de problème et comment je peut le résoudre. Je précise que j'utilise des images de format bmp.

Merci pour votre aide

[Bousk]

Tes images sont mal placées et/ou le path pour les charger est incorrect.

[geek12]

Je vous remercie pour votre réponse. Les images que j'utilise sont chargées avec l'inspecteur d'objet via la propriété Glyph. Je ne vois pas comment elles peuvent être mal placées. Je vous remercie de me guider plus.

[koala01]

Salut,

Je vous remercie pour votre réponse. Les images que j'utilise sont chargées avec l'inspecteur d'objet via la propriété Glyph. Je ne vois pas comment elles peuvent être mal placées. Je vous remercie de me guider plus.

Bousk a parfaitement raison : le chemin d'accès pour accéder à tes images est, de toute évidence, mauvais lorsque ton application s'exécute en dehors de ton EDI.

On va essayer d'être simple:

Quand ton application est exécutée, le système d'exploitation part d'un dossier bien particulier pour pouvoir la lancer. C'est ce que l'on appelle le "dossier d'exécution".

Ce dossier d'exécution est -- généralement -- clairement défini par ton EDI, quel qu'il soit, pour s'assurer que l'ensemble des fichiers auxquels tu essayera d'accéder soient effectivement disponibles.

Lorsque tu lances ton exécutable depuis "l'extérieur" de ton EDI, le dossier d'exécution défini par ton EDI ne peut pas être pris en compte, pour la simple et bonne raison que ton EDI n'est pas utilisé.

Si tu ne définis pas toi-même le dossier d'exécution de manière à ce qu'il soit identique à celui qui est utilisé par ton EDI, ton application ne pourra pas trouver les fichiers auxquels tu essayes d'accéder. C'est aussi simple que cela.

Pire encore: Il arrive régulièrement que tu essaye d'installer ton application sur un ordinateur différent de celui sur lequel elle a été développée. On appelle cette étape le déploiement.

Si tu ne penses pas à copier les fichiers dont ton application a besoin au bon endroit (par rapport à l'exécutable de ton application) sur l'ordinateur qui devra l'exécuter, il n'y a forcément aucune chance pour que ton application soit capable de trouver les fichiers en question, vu qu'ils ne seront pas ** physiquement ** dans les dossiers dans lesquels elle espère les trouver (et que ces dossiers ont d'ailleurs de grandes chances de ne pas exister).

L'idéal, est donc de prévoir, à chaque fois que tu essaye d'accéder à un fichier bien particulier, est -- dans un premier temps du moins (on va dire: au moins jusqu'à ce que tu aies pu déterminer clairement quel est le dossier d'exécution ou les chemins d'exécution qui permettront d'accéder aux fichiers) -- de s'assurer de manière systématique que le fichier auquel tu souhaite accéder existe bel et bien avant d'essayer de l'utiliser, et de provoquer le lancement d'une exception si ce n'est pas le cas.

[foetus]

L'idéal, est donc de prévoir

Non l'idéal est de transformer ces images en ressources, et ensuite de les donner au composant.

Parce qu'une ressource est "mise" dans l'exécutable. Par contre, je ne sais plus comment faire (à part avec un fichier .rc à l'ancienne) ... il y a sûrement une option dans le menu parce qu'1 propriété (truc spécifique à Delphi) correspond à une option IDE.

Et c'est bien le cas La classe Glyph dérive de TBitmap et elle a 2 méthodes publiques : LoadFromResourceID et LoadFromResourceName

[koala01]

Mais, même avec une ressource, on peut toujours douter de la présence du fichier dans la ressource en question.

Donc, même si le PO se met à créer la ressource ad-hoc, l'obtention d'un message explicite indiquant que le fichier recherché n'existe pas reste une sécurité à ne pas sous-estimer, même s'il ne doit s'agir que d'une assertion, qui sera supprimée (normalement) à la fin de la période debug

[foetus]

Mais, même avec une ressource, on peut toujours douter de la présence du fichier dans la ressource en question.

Justement , avec 1 ressource, il n'y a plus de chemin (*) ni de fichier à proprement donné : les données sont copiées en "dur" et tu as un identifiant.

Donc le seul problème c'est que l'identifiant n'existe pas mais de souvenirs avec l'IDE Delphi/ C++ Builder tu ne peux pas vraiment te tromper contrairement à un chemin (qu'il faut vérifier que l'IDE ne te mette pas un chemin relatif par exemple) ... à moins de ne pas passer par l'IDE, et de le coder.
et avec l'utilitaire Resource Hacker (ResHack), tu peux vérifier toutes tes ressources.


*: tu as un chemin mais dans tes ressources. Mais tu n'as plus de chemin disque dur, relatif ou absolu parce que je pense que le problème doit être un chemin relatif

l'obtention d'un message explicite indiquant que le fichier recherché n'existe pas reste une sécurité à ne pas sous-estimer, même s'il ne doit s'agir que d'une assertion, qui sera supprimée (normalement) à la fin de la période debug

C'est un peu le problème : le composant n'affiche rien s'il ne trouve pas l'image. Peut-être qu'avec une ressource, tu as une exception du style "resource id not found" parce qu'elle vient de Windows.

[geek12]

Merci à tout le monde pour votre support.
J'ai résolu mon problème. Il s'agit d'un mode de compatibilité appliqué par Windows qui empêche l'affichage des images ".bmp" au niveau des TspeedButton. En effet mon appli se lance en mode de compatibilité Windows XP SP2 alors que j'utilise windows 10. En désactivant ce mode de compatibilité, je n'ai plus le problème.
Merci de nouveau pour votre support.