Discussion :

[Jipété]

Merci pour ton retour

Sinon il y a 2 erreurs dans la fonction MakeCircle

sous Linux ou sous Windows ?
Et comment se fait-il ne je n'aie jamais eu ces erreurs ?

[BeanzMaster]

Merci pour ton retour


sous Linux ou sous Windows ?
Et comment se fait-il ne je n'aie jamais eu ces erreurs ?

Sous Windows et oui bizarre surtout la Division par zero qui est inévitable dans ton code. Une option dans le projet ou l'ide de ton coté ?
Je testerai sous Linux un peu plus tard

[Jipété]

Sous Windows et oui bizarre surtout la Division par zero qui est inévitable dans ton code. Une option dans le projet ou l'ide de ton coté ?

Pas que je sache.
Bon, c'est déjà publié, de l'autre côté.

Je testerai sous Linux un peu plus tard

Oui, avec plaisir.

Ah j'en ai trouvé un tout seul, alors profite :
Dans ComputeOptimalSizes;, tout en bas :

Code :

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

1
2
3
4
5
  ...
    memo1.Visible   := False;
//    Height := pnl4courbes.Top + pnl4courbes.Height + ckbxFirstLine.Height + 10;
  {$ENDIF}
end;

à commenter sinon impossible de passer en plein écran.

[BeanzMaster]

Sous Windows et oui bizarre surtout la Division par zero qui est inévitable dans ton code. Une option dans le projet ou l'ide de ton coté ?
Je testerai sous Linux un peu plus tard

Je viens de tester sous Linux aucunes exceptions levées

du coup après une petite recherche vite fait, voici le pourquoi : http://wiki.lazarus.freepascal.org/M...FPU_exceptions

Gtk2 and masking FPU exceptions
Gtk2 library changes the default value of FPU (floating point unit) exception mask. The consequence of this is that some floating point exceptions do not get raised if Gtk2 library is used by the application. That means that, if for example you develop a LCL application on Windows with win32/64 widgetset (which is Windows default) and plan to compile for Linux (where Gtk2 is default widgetset), you should keep this incompatibilities in mind.
......
However, with Gtk2, only exOverflow is not masked.

The consequence is that EInvalidOp and EZeroDivide exceptions do not get raised if the application links to Gtk2 library]! Normally, dividing non-zero value by zero raises EZeroDivide exception and dividing zero by zero raises EInvalidOp

Le problème c'est que ce genre de chose peut entrainer des erreurs "en mémoire"

A+

[Jipété]

Le problème c'est que ce genre de chose peut entrainer des erreurs "en mémoire"

Des grands malades ! C'est vraiment des grands malades pour inventer un système où les erreurs sont gérées dans un environnement et pas dans l'autre.

Tu m'anéantis avec cette information.
Et combien de blagues similaires planquées au coin du bois et prêtes à nous sauter dessus pour nous agresser dès la nuit tombée, mmmh ?

Bref, merci à toi d'avoir fouillé et levé ce lièvre, à charge pour nous de ne pas l'oublier.

[Jipété]

Salut salut,

je me suis amusé à créer un projet minimaliste reprenant la map de 24 couleurs pour tester sous Windows, et les galères commencent.

et il faut modifier

pos_px := (w+rayon); par pos_px := (w+rayon)-1; sinon SIGSEGV --> Index hors limite dans la ligne (on commence a zero. Si la largeur = 100px Index Max = 99px)

Obligé de conserver pos_px := (w+rayon); parce que l'ajout du -1 génère des indices négatifs pas bons du tout. M'en suis sorti avec un balayage configuré ainsi : w := -rayon to rayon-1, et si je poste ce soir, c'est parce que j'ai une autre sale blague, que personne n'a relevé et que je suspecte donc d'être attachée au fait que dans ce nouveau projet light j'ai fait sauter tout ce qui avait un rapport avec le redimensionnement du TImage d'affichage (et les TBitmaps sous-jacents) et son adaptation à une division par 24.

Résultat des courses, cette horreur à droite :


Et j'en ai des pires. Tu n'as pas vu ça chez toi ?

[Jipété]

Bonjour,

Dans tout ce qui suit je me concentre sur la partie droite, la partie gauche n'ayant pas de soucis.

J'ai réglé le problème en forçant les dimensions du TImage à des valeurs divisibles par 24. Je suspecte que le défaut d'origine soit en rapport avec des valeurs fantaisistes liées au padding des lignes du bitmap sous-jacent, c'est le problème quand on bricole avec RawImage, pRGBtriple et ce genre de choses bas niveau.



Vous remarquerez dans la barre de titre du prog en mode "étude" des valeurs concernant le TImage qui ne correspondent pas à la réalité et ça, c'est un brave mystère et un sacré piège !

Le TImage est Align := alClient, son espace vital est déterminé par les panneaux qui le bordent, ces 4 panneaux d'encadrement sont inclus dans un autre, qui a une largeur de 217 et une hauteur de 279 (valeurs "exotiques" pour mettre en évidence les défauts d'alignement).

Si je fais 217 - (12 + 13) ça donne 192, parfaitement divisible par 24 (= 8). Pourquoi l'image affichée correctement annonce-t-elle 157 dans la barre de titre (qui est sa valeur à la conception, l'autre c'est 179) ?
Même remarque avec la hauteur : 279 - (43 + 44) = 192, donc le TImage est bien à 192 x 192 (ce qui est le but recherché), et ce n'est pas du tout ce qui est affiché.

Les choses se passent dans une procédure qui au début redimensionne les panneaux, correctement comme on peut le voir, et à la fin affiche les dimensions du TImage, en vrac alors que l'objet est correct.
Si vous avez des calculs basés là-dessus, vous êtes mort.

Ça m'épuise, des choses pareilles, ça me fait perdre un temps dément, et ce résultat débile est identique sous Linux comme sous XP.
C'est quand même fou d'avoir un truc aussi aléatoirement peu fiable.
Non ?