Discussion :

[inforock]

Bonjour,

Ne pas confondre la cause et l'effet : c'est parce que la variable est vide dans l'environnement Linux que le programme qui s'appuie sur GetEnvironmentVariable affiche une ligne vide.

Dans mon environnement LINUX, les variables LC_xxxx sont correctement renseignées pour moi. La commande locale affiche comme résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
LANG=fr_FR.UTF-8
LANGUAGE=fr_FR
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=

Je pense donc (mais cela n'engage que moi) qu'il y a un pb pour récupérer les valeurs des variables LC_xxxxx. J'avais un programme écrit en C qui listait le contenu de ces variables. Il faut que je le retrouve pour voir ce qu'il me donne comme résultat.

J'essaierais de comprendre pourquoi un peu plus tard car, au fin fond de la Bretagne (Finistère nord), il fait un super soleil donc cet après-midi, ca va être ballade et ... peut-être plage

Cdt

Laurent

[Jipété]

D'après man locale il y aurait un dossier intéressant à voir, /usr/lib/locale/ et là-dedans je trouve un dossier C.UTF-8 qui contient (entre autres) un fichier LC_CTYPE pesant 151984 octets et qui, regardé avec mc, ne ressemble à rien : un micmac de texte et de binaire, toujours est-il que chez moi la commande locale est capable d'en extraire des choses :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
LANG=fr_FR.UTF-8
LANGUAGE=
LC_CTYPE="fr_FR.UTF-8"
...

On notera la présence des guillemets alors que LANG ne les a pas.

Bon, essaye de retrouver ton code en C, qu'on s'éclate ! Parce que 151984 octets juste pour une string de quelques caractères, ça m'intrigue

Et 'tention les coups de soleil, hein

[BeanzMaster]

Hello

Parce qu'elle est renseignée dans l'OS.

Tiens, tu devrais rajouter un truc genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
  fbl := Copy(GetEnvironmentVariable('LC_CTYPE'), 1, 2);
  if fbl = '' then
   fbl := Copy(GetEnvironmentVariable('LANG'), 1, 2);
  if fbl = '' then signale_erreur_et_invalide_la possibilité_de_changer_de_langage

De mon côté, en utilisant LANG dans gvtranslate le label de test est bien rempli avec 'fr' mais basculer la combo sur 'en' ne change pas le fait que l'appli redémarre en 'fr'.
Go figure...

Merci j'y ai pensé
et je vais rajouté un test sur GetEnvironmentVariable('LANGUAGE') qui est chez toi renseigné et si j'ai bien lu la doc que tu as envoyé hier cette variable écrase LANG et LC_CTYPE

J'ai rajouté ça showmessage(inttostr(Application.ParamCount) +' '+Language); à la fin du gvlanguage.Create;, compil, exécution hors EDI, ça donne "0 fr" je modifie en "en" ça redémarre et ça donne "3 en", cool, sauf que la combobox affiche toujours "fr".

Merci je vais regardé car j'ai le même problème souc MacOS

Même pas besoin, j'ai retrouvé une vieille procédure StretchDown notée "AndNotor" () qui fonctionne du feu de Dieu et qui, contrairement à son nom, peut aussi faire du StretchUp, testé avec un fichier tordu de 177x111, tout juste bon à planter mes vieilles routines et là, nickel chrome !

Plus qu'à y adapter la prise en compte du canal alpha et mon bonheur sera complet !

Normalement le code que tu fournis ici devrais parfaitement fonctionner avec un bitmap 32 bit.

À dresser à préparer à servir à faire la vaisselle ? Vi, je compatis,
Bon week-end, repose-toi,

Ouep exactement c'est éreintant, pour ça moi le week-end tu ne me demande pas de mettre les pieds dans une cuisine.
Après avoir servis plus de 500 assiettes dans la semaine, tu m'oublis.

Bon wee-end également

[inforock]

Bonjour,

Bon, essaye de retrouver ton code en C, qu'on s'éclate ! Parce que 151984 octets juste pour une string de quelques caractères, ça m'intrigue

Je viens d'essayer un bout de code en C, et les contenus des variables LC_xxxx sont correctement affichés (utilisation de setlocale avec le header locale.h).

Le code (je sais ce n'est pas du pascal ) :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include <stdio.h>
#include <stdlib.h>
#include <locale.h>
 
int main()
{
    char *resultat;
    setlocale(LC_ALL,"");
    resultat = setlocale(LC_CTYPE,NULL);
    printf("Variables d'environnements locales :\n");
    printf("LC_CTYPE = %s \n",resultat);
    printf("LC_NUMERIC = %s \n",setlocale(LC_NUMERIC, NULL));
    printf("Fin du programme\n");
    return 0;
}

Le résultat affiché est :

Variables d'environnements locales :
LC_CTYPE = fr_FR.UTF-8
LC_NUMERIC = fr_FR.UTF-8
Fin du programme

La fonction setlocale récupère donc correctement la valeur de la variable d'environnement qui lui est passée en paramètre.

Voyant ce résultat, mais je peux me tromper, pour moi, le pb viendrait plutôt de la fonction GetEnvironmentVariable de FreePascal. N'y aurait-il pas un pb d'Unicode quelque part ?

Mais je suis en train de polluer ce fil avec un tout autre sujet

Bon après-midi.

Cdt

Laurent

[Jipété]

Variables d'environnements locales :
LC_CTYPE = fr_FR.UTF-8
LC_NUMERIC = fr_FR.UTF-8
Fin du programme

Même résultat chez moi avec ton petit prog qui a compilé sans se prendre la tête une seconde

le pb viendrait plutôt de la fonction GetEnvironmentVariable de FreePascal.

Pas bête !

Mais je suis en train de polluer ce fil avec un tout autre sujet

Pas du tout, ça fait partie des options du GifViewer,

et je vais rajouter un test sur GetEnvironmentVariable('LANGUAGE') qui est chez toi renseigné

Non !
C'est LANG qui est renseigné, LANGUAGE est vide !
Sortie du prog Debian locale (juste le début) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
LANG=fr_FR.UTF-8
LANGUAGE=
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"

Ça épuise, les assiettes,

Normalement le code que tu fournis ici devrait parfaitement fonctionner avec un bitmap 32 bit.

Je n'en doute pas, le problème c'est qu'on se souvient que bmp.PixelFormat n'est pas fiable du tout et qu'il faut passer par la lecture et l'analyse du header si on bosse avec un fichier, ou s'en fabriquer un si on bosse en mémoire avec un TBitmap.

Donc je regarde ça dès que j'ai 5 minutes : là j'ai la pompe d'arrosage qui s'est désamorcée et je n'arrive pas à la réamorcer.
Et par ces chaleurs, ce n'est pas raisonnable...

[inforock]

Bonsoir,

Je pense avoir trouvé une solution pour accéder aux valeurs des variables LC_xxxxx

En fait, dans l'unité clocale, il y a la définition de la fonction setlocale. Mais les constantes qui y sont liées sont incomplètes (il n'y en a que 6 de définies alors qu'en réalité il en existe 12).

J'ai donc créé ce code pour utiliser la fonction setlocale et redéfinir (enrichir) les constantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
unit u_setlocale;
 
{$mode objfpc}{$H+}
 
interface
 
{$linklib c}
 
uses
  Unix,  // Pour la définition de cint
  initc; // Pour la définition de clib
 
const
  LC_CTYPE          = 0;
  LC_NUMERIC        = 1;
  LC_TIME           = 2;
  LC_COLLATE        = 3;
  LC_MONETARY       = 4;
  LC_MESSAGES       = 5;
  LC_ALL            = 6;
  LC_PAPER          = 7;
  LC_NAME           = 8;
  LC_ADDRESS        = 9;
  LC_TELEPHONE      = 10;
  LC_MEASUREMENT    = 11;
  LC_IDENTIFICATION = 12;
 
function setlocale(category: cint; locale: pchar): pchar; cdecl; external clib name 'setlocale';
 
implementation
 
end.

Après avoir ajouté l'unité dans les uses d'un petit programme de tests, j'appelle la fonction setlocale en indiquant la variable LC dont je veux la valeur. Exemple d'appel : setlocale(LC_CTYPE,'')

Et ça m'affiche bien la valeur de la variable ! En tout cas, dans mon environnement ...

L'exemple d'utilisation de la fonction GetEnvironmentVariable est faux sur le wiki de freepascal. En effet, l'exemple utilise la variable locale LC_CTYPE or la fonction ne peut accéder (du moins dans mon environnement) qu'aux variables "globales" et non "locales". Avec cette fonction, j'arrive à afficher toutes les variables qui sont affichées via la commande linux env. Je pense d'ailleurs que c'est pour cela que sous linux, il y a la commande locale qui permet d'afficher les variables LC_xxxxxx --> ce qui implique qu'il faut utiliser une fonction spécifique pour y accéder aussi en pascal.

Toujours en recherchant sur le wiki des infos sur la fonction setlocale, dans la page traitant de i18n et des fichiers po pour les traductions, pour avoir la langue par défaut, ils utilisent GetEnvironmentVariableUTF8 avec la variable d'environnement LANG.

A moins ne pas avoir correctement recherché, la fonction setlocale n'est pas du tout documentée sur le wiki ... et entre l'absence de documentation et un exemple faux, je me suis donc basé sur la définition et l'utilisation en C.

J'ai encore squatté mais ce coup-ci, c'est avec du pascal

Bonne soirée.

Cdt

Laurent

[BeanzMaster]

Bonsoir,

Je pense avoir trouvé une solution pour accéder aux valeurs des variables LC_xxxxx

En fait, dans l'unité clocale, il y a la définition de la fonction setlocale. Mais les constantes qui y sont liées sont incomplètes (il n'y en a que 6 de définies alors qu'en réalité il en existe 12).

J'ai donc créé ce code pour utiliser la fonction setlocale et redéfinir (enrichir) les constantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
unit u_setlocale;
 
{$mode objfpc}{$H+}
 
interface
 
{$linklib c}
 
uses
  Unix,  // Pour la définition de cint
  initc; // Pour la définition de clib
 
const
  LC_CTYPE          = 0;
  LC_NUMERIC        = 1;
  LC_TIME           = 2;
  LC_COLLATE        = 3;
  LC_MONETARY       = 4;
  LC_MESSAGES       = 5;
  LC_ALL            = 6;
  LC_PAPER          = 7;
  LC_NAME           = 8;
  LC_ADDRESS        = 9;
  LC_TELEPHONE      = 10;
  LC_MEASUREMENT    = 11;
  LC_IDENTIFICATION = 12;
 
function setlocale(category: cint; locale: pchar): pchar; cdecl; external clib name 'setlocale';
 
implementation
 
end.

Après avoir ajouté l'unité dans les uses d'un petit programme de tests, j'appelle la fonction setlocale en indiquant la variable LC dont je veux la valeur. Exemple d'appel : setlocale(LC_CTYPE,'')

Et ça m'affiche bien la valeur de la variable ! En tout cas, dans mon environnement ...

L'exemple d'utilisation de la fonction GetEnvironmentVariable est faux sur le wiki de freepascal. En effet, l'exemple utilise la variable locale LC_CTYPE or la fonction ne peut accéder (du moins dans mon environnement) qu'aux variables "globales" et non "locales". Avec cette fonction, j'arrive à afficher toutes les variables qui sont affichées via la commande linux env. Je pense d'ailleurs que c'est pour cela que sous linux, il y a la commande locale qui permet d'afficher les variables LC_xxxxxx --> ce qui implique qu'il faut utiliser une fonction spécifique pour y accéder aussi en pascal.

Toujours en recherchant sur le wiki des infos sur la fonction setlocale, dans la page traitant de i18n et des fichiers po pour les traductions, pour avoir la langue par défaut, ils utilisent GetEnvironmentVariableUTF8 avec la variable d'environnement LANG.

A moins ne pas avoir correctement recherché, la fonction setlocale n'est pas du tout documentée sur le wiki ... et entre l'absence de documentation et un exemple faux, je me suis donc basé sur la définition et l'utilisation en C.

J'ai encore squatté mais ce coup-ci, c'est avec du pascal

Bonne soirée.

Cdt

Laurent

Salut,
excellent Je n'avais pas remarqué l'utilisation de la variable LANG dans le wiki bien vu.

Merci pour cette petite unité qui va être bien utile je pense, à plein de gens

[jurassic pork]

hello,

L'exemple d'utilisation de la fonction GetEnvironmentVariable est faux sur le wiki de freepascal. En effet, l'exemple utilise la variable locale LC_CTYPE or la fonction ne peut accéder (du moins dans mon environnement) qu'aux variables "globales" et non "locales". Avec cette fonction, j'arrive à afficher toutes les variables qui sont affichées via la commande linux env.

moi aussi je pense que l'exemple est faux pour un système unix car en effet par exemple sous Lubuntu 16.04 env ne retourne pas les variables de type LC_ mais il retourne LANG. Voici ce qui est dit concernant les spécifications des variables d'environnement sous UNIX :

• LANG This variable determines the locale category for native language, local customs and coded character set in the absence of the LC_ALL and other LC_* (LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, LC_TIME) environment variables. This can be used by applications to determine the language to use for error messages and instructions, collating sequences, date formats, and so forth.
• LC_ALL This variable determines the values for all locale categories. The value of the LC_ALL environment variable has precedence over any of the other environment variables starting with LC_ (LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, LC_TIME) and the LANG environment variable.
• LC_CTYPE This variable determines the locale category for character handling functions, such as tolower(), toupper() and isalpha(). This environment variable determines the interpretation of sequences of bytes of text data as characters (for example, single- as opposed to multi-byte characters), the classification of characters (for example, alpha, digit, graph) and the behaviour of character classes. Additional semantics of this variable, if any, are implementation-dependent.

Comme on peut le constater la variable LANG est plus appropriée pour des applications. LC_CTYPE c'est plutôt (pas le chien) pour du bas niveau genre routine C système.

Ami calmant, J.P (sans T)

[BeanzMaster]

Hello

Petite mise à jour effectuée.

- La traduction fonctionne mainteant sous mac, windows et linux (du moins chez moi)

PS : Gilles j'espère que tu ne m'en voudras pas, je me suis réapproprié ton composant TGVTranslate. Je l'ai entièrement réécris. Son petit nom "TBZApplicationTranslator". Je n'ai bien sur pas manquer de te citer dans les crédits et mis un lien vers ton tuto

@Jipete : Ce coup-ci j'espère que ça va fonctionner chez toi

[Jipété]

Salut,

@Jipete : Ce coup-ci j'espère que ça va fonctionner chez toi

ça dépend de ce qu'on entend par "fonctionner" :
- le fait de choisir "en" fait redémarrer le prog, qui me marque bien "en" en haut à droite, donc ça, ça fonctionne ;
- mais l'ihm au redémarrage est toujours en français.

Donc ou bien je n'ai pas compris à quoi sert cette histoire de traduction, ou bien quelque chose de plus profond m'échappe...

Pas le temps de creuser plus, aujourd'hui (et la pompe est toujours en panne...)

[Jipété]

Je tombe sur un article, dans le forum voisin, où l'image gif attire mon attention, alors comme j'ai un viewer de la mort qui tue à disposition (), je me suis dit que j'allais l'utiliser pour examiner en profondeur ce gif où une image entr'aperçue rapidement m'intrigue, et comme "dans la vie tout sert à tout", comme je dis toujours, ben... bim :



PS : le viewer de Linux (en haut) s'en sort bien, ainsi que XnView sous XP...
Et The Gimp m'a permis de trouver cette image bizarre (la 65 en comptant en partant de 1) qui, en effet, comporte un artefact : la zone mauve et bleue en haut à gauche -- pas au point, leur IA,



EDIT :
bonne ou mauvaise nouvelle ?
Le fait d'avoir demandé à The Gimp de réexporter les 259 images sous un autre nom a généré un fichier un poil plus petit (998 080 vs 999 118), et qui s'ouvre bien !
Vue de l'artefact :

[BeanzMaster]

Salut

Salut,


ça dépend de ce qu'on entend par "fonctionner" :
- le fait de choisir "en" fait redémarrer le prog, qui me marque bien "en" en haut à droite, donc ça, ça fonctionne ;
- mais l'ihm au redémarrage est toujours en français.

Donc ou bien je n'ai pas compris à quoi sert cette histoire de traduction, ou bien quelque chose de plus profond m'échappe...

Pas le temps de creuser plus, aujourd'hui (et la pompe est toujours en panne...)

Arg, Non tu as bien compris l,IHM devrait être traduite en anglais. Là ce qui est bizarre c'est que "en" s'affiche bien. Est ce que les fichiers PO sont bien ceux du GitHub ? au cas ou. Car le problème est que soit les fichiers po ont été modifié par Lazarus, mais là je vois pas pourquoi car j'ai décocher dans les options du projet section i18n "Créer/mettre à jour le fichier po". Sinon c'est un problème avec le chemin d'accès, mais je ne comprend pas pourquoi vu que cela fonctionne chez moi sous Manjaro et sous Mon Mac. je vais revérifier sous Linux

EDIT : Un truc bizarre le fichier GifViewerStrConsts.en.po à été modifié à la compilation. Essayes de copier celui se trouvant dans le dossier Local vers le dossier Languages

Je tombe sur un article, dans le forum voisin, où l'image gif attire mon attention, alors comme j'ai un viewer de la mort qui tue à disposition (), je me suis dit que j'allais l'utiliser pour examiner en profondeur ce gif où une image entr'aperçue rapidement m'intrigue, et comme "dans la vie tout sert à tout", comme je dis toujours, ben... bim :

PS : le viewer de Linux (en haut) s'en sort bien, ainsi que XnView sous XP...

Et The Gimp m'a permis de trouver cette image bizarre (la 65 en comptant en partant de 1) qui, en effet, comporte un artefact : la zone mauve et bleue en haut à gauche -- pas au point, leur IA,

EDIT :
bonne ou mauvaise nouvelle ?
Le fait d'avoir demandé à The Gimp de réexporter les 259 images sous un autre nom a généré un fichier un poil plus petit (998 080 vs 999 118), et qui s'ouvre bien !
Vue de l'artefact :

L'affichage est normal dans GifView. vu que les données sont corrompue la plupart des logiciels soit efface cette image de l'animation soit comme Gimp doit dupliqué la N°1. Soit le problème dans GifView se situe dans la decompression LZW en effet lorsque qu'un bloc corrompu est trouvé, je ne me déplace pas de la longueur de celui-ci 5exemple si on se trouve à la position X dans l'image et que la donné corrompue a une longueur de 10 pixels, je reste sur X au lieu de me déplacer et du coup on se retouve avec une très mauvaise représentation vu que les tous les pixels suivants sont décalés. A ce stade j'ai 3 solutions :
1) Me déplacer dans l'image lors de la décompression
2) Supprimer purement et simplement l'image de l'animation
3) Dupliquer l'image suivante ou précédente

Petite question bête dans le viewer Linux et XNView est ce que tu sait combien d'image sont affiché durant l'animation ? 260 ou 259 ?

PS : Je viens de remettre le GitHub à jour, histoire de dire au cas ou (par rapport a ce fichier po)

[Jipété]

Est-ce que les fichiers PO sont bien ceux du GitHub ?

Ils viennent du zip récupéré ce matin.

EDIT : Un truc bizarre le fichier GifViewerStrConsts.en.po a été modifié à la compilation.

Pas chez moi :


Les 3 du haut ont été générés à la compil de 8 h 26, les 3 du bas ont la date des fichiers dans le zip.

Je suspecte un problème de majuscules/minuscules (mais je n'ai pas cherché plus avant).


Ah tiens, pendant que j'y suis, dans bzapplicationtranslator, function TBZApplicationTranslator.GetApplicationPath: String; : pourquoi réinventer la roue ? il existe une fonction ProgramDirectory qui serait multi-plateforme. Teste-la !

Petite question bête dans le viewer Linux et XNView est-ce que tu sais combien d'images sont affichées durant l'animation ? 260 ou 259 ?

XnView : 1 à 259, et il y a un mode image-par-image qui me montre la 1^re image identique entre XnView et The Gimp, idem pour la 2^e, la 3^e, etc.

viewer Linux : Pas d'options pour en savoir plus.

[BeanzMaster]

Ils viennent du zip récupéré ce matin.


Pas chez moi :


Les 3 du haut ont été générés à la compil de 8 h 26, les 3 du bas ont la date des fichiers dans le zip.

Ces fichiers ne devraent pas être compilé.
Lazarus à été mise à jour par mon systeme de la version 1.8.2 à 1.8.4 et bizarrement ce soir impossible de reproduire le bug.

Je suspecte un problème de majuscules/minuscules (mais je n'ai pas cherché plus avant).

Non j'ai vérifié et en plus cela fonctionne chez moi

Ah tiens, pendant que j'y suis, dans bzapplicationtranslator, function TBZApplicationTranslator.GetApplicationPath: String; : pourquoi réinventer la roue ? il existe une fonction ProgramDirectory qui serait multi-plateforme. Teste-la !

Je vais essayer merci, je ne connaissais pas cette instruction

XnView : 1 à 259, et il y a un mode image-par-image qui me montre la 1^re image identique entre XnView et The Gimp, idem pour la 2^e, la 3^e, etc.

viewer Linux : Pas d'options pour en savoir plus.

C'est donc ce que je disais il supprime l'image corrompue de l'animation car à la base il y a 260 images et non 259

Je vais rajouter une propriété pour ne pas afficher les images corrompues.

[Jipété]

C'est donc ce que je disais il supprime l'image corrompue de l'animation car à la base il y a 260 images et non 259

Comment tu sais ça ?

Tiens, TAnimatedGif annonce lui aussi 259 frames et les affiche sans problème.

[BeanzMaster]

Nouvelle mise à jour :

• Ajout de la propriété DisplayInvalidFrames. Par défaut cette propriété est à FALSE. Les images corrompues ne sont donc pas affichées durant l'animation
• Correction des fichiers PO

[BeanzMaster]

Comment tu sais ça ?

Tiens, TAnimatedGif annonce lui aussi 259 frames et les affiche sans problème.

Tout simplement car c'est le nombre affiché. Si ce nombre est erroné, cela voudrais dire que mon composant à tout faux sur toutes les images GIF de la testsuite




Pour ProgramDirectory j'ai trouvé une autre solution Application.Location

[BeanzMaster]

Je viens de faire un petit test

Prend le fichier 6d939393058de0579fca1bbf10ecff25 dans gif89a/badencoded Il s'affiche également bien avec TGigAnim. Mais regardes bien l'animation il y a un temps de pause entre la dernière image et la 1ere. Tu remarqueras qu'il affiche que 3 images et sous Gimp pareil. Pourtant ce fichier comporte 4 images. La dernière est corrompue. Le temps de pause que l'on peux voir c'est que la dernière image est totalement transparente. De plus suivant le "DisposalMode" tu ne t'en rendras même pas compte que cette image existe.

[Jipété]

• Ajout de la propriété DisplayInvalidFrames. Les images corrompues ne sont pas affichées durant l'animation

Pas clair, ça.
Tu vas encore dire que je cherche la petite bête mais je vois une propriété prévue pour afficher les frames invalides mais dont l'action va être de ne pas les afficher

Tout simplement car c'est le nombre affiché. Si ce nombre est erroné, cela voudrais dire que mon composant a tout faux sur toutes les images GIF de la testsuite

Je verrai ça demain mais vit' fait, j'ai regardé avec un prog mal fichu en C qui me donne 2 images avec Diddl (correct), 16 avec girl (correct aussi) et... 259 là où tu trouves 260 !

[BeanzMaster]

Pas clair, ça.
Tu vas encore dire que je cherche la petite bête mais je vois une propriété prévue pour afficher les frames invalides mais dont l'action va être de ne pas les afficher

DisplayInvalidFrame := True affiche les image corrompue. DisplayInvalidFrame := False n' affiche les image corrompue. Par défaut cette propriété est à FALSE.

EDIT : J'ai modifié, pour être plus clair

Je verrai ça demain mais vit' fait, j'ai regardé avec un prog mal fichu en C qui me donne 2 images avec Diddl (correct), 16 avec girl (correct aussi) et... 259 là où tu trouves 260 !

Parce que je compte les images corrompue. Je pourrais aisément soustraire le nombre d'images corrompues pour obtenir exactement le même nombre. Ici j'ai fais le choix de conserver l'image corrompue dans la liste. Mais si je la supprime j'aurais bien 259.