par , 23/03/2017 à 16h51 (1292 Affichages)
S'il est facile de définir à la conception le glyphe qui accompagne un contrôle comme un TBitBtn, sa modification à l'exécution depuis l'exécutable lui-même semble poser plus de problèmes. Pourtant, ne pas utiliser de fichiers séparés de l'exécutable permet d'éviter les erreurs d'accès au support choisi. Alors, pourquoi s'en priver ?
Je vous propose par conséquent quatre façons d'opérer, suivant vos besoins.
1. Utilisation de TImageList
On n'y pense pas toujours, mais le composant TImageList permet souvent de se tirer d'affaire, pour peu qu'on ait besoin d'une série d'images de même taille. En supposant qu'on ait chargé des images dans ce composant, il suffit d'utiliser sa méthode GetImage pour pouvoir affecter un de ses bitmaps à un autre bitmap. Or, la propriété Glyph d'un TBitBtn est justement du type TCustomBitmap
.
En supposant qu'un clic sur le TBitBtn lui-même (appelé ici bitbtnImageList) change son Glyph, on peut écrire quelque chose comme :
1 2 3 4
| procedure TMainForm.bitbtnImageListClick(Sender: TObject);
begin
ImageList.GetBitmap(0, bitbtnImageList.Glyph);
end; |
Ainsi l'image numéro 0 de la liste d'images sera affectée au glyphe du bouton avec image.
2. Utilisation d'un fichier de ressources
C'est la méthode qui a ma préférence, car elle s'adapte à de nombreux cas : contrairement à TImageList, une ressource est entièrement maîtrisée par le programmeur.
Les étapes à suivre sont les suivantes :
- avec un outil comme ResHacker (efficace et gratuit), il faut créer ou compléter un fichier de ressources en y intégrant le bitmap désiré sous un nom si possible parlant ;
- dans le code de l'unité où ce bitmap sera utilisé, il faut placer la directive $R demandant au compilateur d'intégrer le fichier de ressources ;
- il ne reste qu'à utiliser la méthode LoadGlyphFromResourceName de TBitBtn pour récupérer le bitmap à partir de son nom.
Si le fichier de ressources s'appelle essai.res, si le bitmap visé s'appelle calc, si le bouton en question se nomme bitbtnResourceName et s'il s'agit toujours de changer son glyphe lors d'un clic sur lui, voici la portion de code qui peut être utilisée :
1 2 3 4 5 6 7 8 9 10 11 12
|
// on intègre le fichier de ressources dans l'exécutable
{$R essai.res }
// [...]
// gestionnaire de clic sur le bouton
procedure TMainForm.bitbtnResourceNameClick(Sender: TObject);
begin
bitbtnResourceName.LoadGlyphFromResourceName(HInstance, 'calc');
end; |
HInstance est une fonction qui fournit le premier paramètre nécessaire à la méthode : elle est disponible en même temps que le bouton.
Il faut aussi noter que le fichier dont l'extension est .res est à l'origine un type de fichier réservé à Windows, mais que Lazarus a choisi ce format comme format standard, y compris pour une plate-forme comme Linux. Il faut donc oublier, même si elle reste accessible, la possibilité d'utiliser des fichiers de ressources spécifiques aux anciennes versions de Lazarus, dont l'extension est .lrs, ainsi que la méthode LoadGlyphFromLazarusResource qui les accompagnait.
3. Utilisation de la propriété Kind
Même si elle ne concerne que les quelques boutons prédéfinis, la propriété Kind n'est pas à négliger. Déjà, son emploi est simple puisqu'il suffit de lui affecter la valeur désirée pour que le glyphe change (ainsi que la propriété ModalResult qui l'accompagne).
Toujours avec l'exemple d'un bouton (appelé bitbtnKind) qui change son propre glyphe, on écrira :
1 2 3 4
| procedure TMainForm.bitbtnKindClick(Sender: TObject);
begin
bitbtnKind.Kind := bkHelp;
end; |
Bien sûr, on se trouve limité puisque la constante à affecter ne peut venir que de la liste fournie par la LCL avec le type TBitBtnKind :
1 2 3
| TBitBtnKind = (bkCustom, bkOK, bkCancel, bkHelp, bkYes, bkNo,
bkClose, bkAbort, bkRetry, bkIgnore, bkAll,
bkNoToAll, bkYesToAll); |
4. Utilisation de la méthode LoadGlyphFromStock
Une dernière possibilité s'offre : celle d'une méthode peu utilisée, mais qui est elle aussi d'un accès très simple, à savoir la méthode LoadGlyphFromStock. Comme son nom l'indique, elle va puiser dans le stock des images disponibles dans la LCL, toutes identifiées par des constantes selon le tableau suivant :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
| idButtonBase = 0;
idButtonOk = idButtonBase + 1;
idButtonCancel = idButtonBase + 2;
idButtonHelp = idButtonBase + 3;
idButtonYes = idButtonBase + 4;
idButtonNo = idButtonBase + 5;
idButtonClose = idButtonBase + 6;
idButtonAbort = idButtonBase + 7;
idButtonRetry = idButtonBase + 8;
idButtonIgnore = idButtonBase + 9;
idButtonAll = idButtonBase + 10;
idButtonYesToAll = idButtonBase + 11;
idButtonNoToAll = idButtonBase + 12;
idButtonOpen = idButtonBase + 13;
idButtonSave = idButtonBase + 14;
idButtonShield = idButtonBase + 15; |
Là encore, une simple affectation modifie le glyphe en cours (mais sans affecter d'autres propriétés) :
1 2 3 4
| procedure TMainForm.bitbtnFromStockClick(Sender: TObject);
begin
bitbtnFromStock.LoadGlyphFromStock(idButtonYesToAll);
end; |
Attention cependant à certaines actions auxquelles n'est associé aucun bouton : idButtonSave ou encore idButtonOpen.
Fort de ces quatre possibilités, vous n'avez plus d'excuses pour laisser vos malheureux TBitBtn bien tristes avec leurs glyphes sans saveur
.