Salut, Gilles !
Je l'ai vécu aussi :Citation:
Envoyé par gvasseur58
Citation:
Envoyé par Jipété
Le mieux je pense, c'est dans un premier temps te renvoyer à la source du prog, tout en bas il y a un lien pour le DL.Citation:
Envoyé par gvasseur58
Version imprimable
Salut, Gilles !
Je l'ai vécu aussi :Citation:
Envoyé par gvasseur58
Citation:
Envoyé par Jipété
Le mieux je pense, c'est dans un premier temps te renvoyer à la source du prog, tout en bas il y a un lien pour le DL.Citation:
Envoyé par gvasseur58
Je croyais que ce problème était résolu : sinon, d'où viendraient les copies d'écran ? :cfou:Citation:
Envoyé par Jipété
Bon, là, ça va être plus long, car je pensais seulement me pencher sur le problème d'affichage :aie:. S'il faut en plus résoudre les problèmes de passage d'un vieux programme Delphi (sans doute impossible à compiler aujourd'hui) vers Lazarus, c'est une autre histoire :mouarf:.Citation:
Le mieux je pense, c'est dans un premier temps te renvoyer à la source du prog, tout en bas il y a un lien pour le DL.
Ben, de ma machine de prod', sous Linux Debian 7/32 :PCitation:
Envoyé par gvasseur58
Ah vi, c'est du D3, ça nous rajeunit pas, :lol:Citation:
Envoyé par gvasseur58
Bah, te prends pas la tête, puisque j'ai trouvé une solution de contournement.
Salut JP,
Un vrai truc de fou ton histoire de décalage des RadioItems !
Sous Windows, pas de problèmes, mais sous Linux mint : décalage lors du mousemove sur l'image.
J'ai remarqué que pour éviter cela, il fallait changer d'onglet (sans passer au-dessus de l'image !), puis revenir au VisibleLight.
Si tu prends un repère visuel, tu verras que les items sont alignés comme au démarrage (et ne bougent plus).
En changeant de page active, le radiogroup est donc bien aligné !!!
Dans l'EDI : je fixe la page active du PageControl = TabSheetVisibleLight
Dans la procedure OnShow de la fiche :
Ce n'est évidemment pas joli joli comme code... mais cela semble prouver qu'il y a un bug d'affichage sous Linux (pour le radiogroup ? ou pour le TabSheet ?).Code:
2PageControlSpectra.ActivePage:= TabSheetRGBGraph; // j'oblige le changement PageControlSpectra.ActivePage:= TabSheetVisibleLight;
Si quelqu'un a une explication...
Cordialement
Thierry
Yep, Thierry !
Merci de ton retour et de tes premiers commentaires, qui me font chaud au cœur, il y a des moments où je me sentais vraiment seul et incompris, sur ce coup-là !
Citation:
Envoyé par ThWilliam
Moi j'avais remarqué que l'auteur fixait la page active au premier onglet dans le FormCreate, sans doute pour s'affranchir d'une modif sur un autre onglet et oubli de rebasculer sur le premier onglet (à qui ça n'est pas arrivé, ce gag ? :mrgreen:), mais pour que ta solution (ou la mienne, lire la ligne suivante) fonctionne, il faut vraiment que la fiche soit visible car forcer un autre onglet dans l'edi et exécuter ne règle rien.Citation:
Envoyé par ThWilliam
Donc il faut passer par ta méthode (que je n'ai pas testée, je l'avoue humblement, j'ai peur d'un flickering vraiment visible) ou par celle que j'ai trouvée, qui consiste à ajouter RadioGroupSpectra.ReAlign; dans le FormActivate.
Mais dis-moi, tu n'as pas eu de souci à travailler sous Windows ? Parce qu'on dirait que Gilles est en train de misérer dans cet environnement...
Du souci sous Windows ? Oui, j'ai dû déconnecter la procédure UpdateImage sinon j'avais une magnifique exception "external: SIGSEGV". Par contre, l'affichage est bon. On ne peut pas tout avoir ! ;)
J'avoue ne pas m'être trop penché sur cette procédure, mais un truc m'a étonné :
Après la ligne "LineWidth := BitmapSpectrum.RawImage.Description.BytesPerLine;", j'ai rajouté un ShowMessage pour m'indiquer la valeur. LineWidth = 1800 soit 3*600 (600= la largeur du bitmap). Le bitmap est donc codé en 24 bits. Or tu utilises "pRGBQuad" qui est un pointeur sur 4 octets. Je ne comprends pas très bien ton scanline. Mais l'essentiel est que cela marche !
Thierry
:evilred:Citation:
Envoyé par ThWilliam
Tout à fait ! C'est ce qu'on voit dans le FormCreate, BitmapSPectrum.PixelFormat := pf24bit; et pour expliquer le pointeur sur 4 octets, on peut lire plus loin, dans la proc UpdateImage, if BitmapSpectrum.PixelFormat = pf32bit then rgbReserved := 0; : il y a bien un quatrième membre au pRGBQuad, en plus des trois couleurs.Citation:
Envoyé par ThWilliam
Maintenant, ne me demande pas pourquoi :mrgreen:
Sinon, pour essayer d'y voir clair, j'ai repris le projet et lui ai tout enlevé sauf le strict minimum (le TImage et le TRadioGroup, un TLabel et un TShape cachés) pour voir un peu, et le problème est toujours présent...
En pj le zip pour ceux qui sont curieux... Pièce jointe 209706
Et ça fait une belle démo d'arc-en-ciel et de scanline :ccool:
Salut JP,
Testé ton projet Laztest :
sous Linux Mint : image ok, mais toujours le problème d'alignement. Ta solution "realign" marche bien (même avec tous les composants visibles). Ce qui marche aussi (par exemple) c'est de modifier la propriété AutoFill (false dans l'Edi, true dans FormActivate). Je crois qu'on peut conclure à un bug dans le TRadioGroup (ou ancêtre) de Lazarus.
sous Windows 7 : pas de décalage d'alignement. Ta procédure UpdateImage ne soulève plus d'exception. Mais avec pRGBQuad, j'ai une magnifique alternance de lignes blanches et noires ! Ce qui me paraissait logique puisque le bitmap est en 24 bits. En utilisant pRGBTriple, l'image est ok. Curieux cette différence de comportement avec Linux.
Cordialement
Thierry
Bonjour,
En fait, il me semble que Linux utilise systématiquement un format interne sur 32 bits avec un canal alpha qui ne sert éventuellement pas, alors que sous Windows, c'est adapté.
Ce pourquoi il n'est pas conseillé de travailler sur le RawImage, le TBitMap présentant une abstraction indépendante de l'OS.
Cela dit, l'équivalent du Scanline manque vraiment...
Bonjour Yves,
Bien vu bien vu bien vu !Citation:
Envoyé par tourlourou
Ça m'a turlupiné, j'ai fait un test à la fraîche, et bingo !
Dans mes essais de ScanLine, j'avais noté Bitmap.PixelFormat := pf24bit; // pf32bit --> image vide ! et je n'étais pas allé plus loin, je voulais à l'époque faire avancer ce sur quoi j'étais, et qui utilisais Scanline et, sous Linux en mode rgbQuad, le 4e membre fonctionnait ainsi, dans la boucle de scan : if Bitmap.PixelFormat = pf24bit then rgbReserved := 0;.
Hé bien j'ai le plaisir d'annoncer qu'en passant le PixelFormat à pf32bit, je peux jouer avec... la transparence !
Le TImage est posé sur le TShape, et rgbReserved est à 127 :
Pièce jointe 209874
Voili voilou :ccool:
Merci pour la piste, Yves, et bonne journée à tous.
Yop !
Étudions aujourd'hui le comportement d'une Listview avec if lvFiles.Items.Count > 0 then lvFiles.Selected := lvFiles.Items[0];.
À gauche Linux, à droite XP :
Pièce jointe 281804
Le temps que j'ai perdu à me demander pourquoi Q307, le premier item de la liste, n'était pas sélectionné, puis à essayer des trucs et des machins pour essayer d'y arriver, même pas vous pouvez l'imaginer...
Jusqu'à ce que j'aie l'idée de tirer l'ascenseur (img en bas à gauche) et là, stupéfaction, je demande lvFiles.Items[0] et donc on me donne lvFiles.Items[lvFiles.Count-1] !
Enfin, "on me donne" à moitié car l'image correspondante n'est pas affichée.
Vraiment une grosse bouse cette ListView, hélas...
Et je ne parle pas du tri alphabétique, c'est carrément n'importe quoi.
Salut Jipété !Citation:
Envoyé par Jipété
Il me semble que tu retombes sur des problèmes similaires dès que tu utilises des contrôles natifs.
En fait, tu peux te représenter la LCL comme une double arborescence de classes. La première est celle que nous utilisons en "surface" :
TComponent
--TLCLComponent
----TControl
------TWinControl
--------TCustomListView
TListView
C'est celle qui est indépendante de la plate-forme et qui permet d'écrire un seul code pour effectuer une tâche, quelle que soit la plate-forme.
La seconde hiérarchie (baptisée widgetset) est l'interface que Lazarus offre pour une bibliothèque native : WinAPI, GTK...
La LCL est par conséquent une passerelle, une interface, entre la partie indépendante (TButton, par exemple) et la partie native (gtk_button sur GTK par exemple).
On peut représenter cette structure double ainsi :
Code
|
Classes LCL <--> Classes Widgetset
| ---------------------- |
FCL et RTL ------ Bibliothèque Widgetset (Windows, GTK...)
| ---------------------- |
Système d'exploitation
Les barres verticales et les signes < et > indiquent une communication possible ; les - sont là pour la présentation donc SANS communication.
(NB : le code peut accéder directement à la FCL et à la RTL qui contiennent des outils divers)
L'avantage de cette double hiérarchie est qu'elle ne nécessite qu'un changement de WidgetSet pour que le code écrit puisse être identique avec un fonctionnement fortement similaire.
Mais il y a plusieurs problèmes subséquents : toutes les classes de la LCL n'ont pas forcément leur traduction dans le WidgetSet et toutes les fonctionnalités d'une classe ne sont pas forcément disponibles dans tous les WidgetSets...
Plusieurs solutions :
- on réécrit tous les contrôles de A à Z sans faire appel aux contrôles natifs (fpGUI), mais le travail est énorme et ne contente pas l'utilisateur final qui a ses habitudes suivant l'OS utilisé ;
- on accepte que tout ne soit pas disponible pour garder le feel and touch de l'environnement.
Inutile de préciser que ces solutions ont leurs avantages et leurs inconvénients...
Problème annexe : si l'on ne connaît pas les possibilités exactes de tel ou tel contrôle pour un OS donné, on distingue mal ce qui peut relever d'un problème inhérent à l'implémentation dans la LCL et ce qui provient tout simplement des limitations de l'OS...
Tu auras compris que ListView, qui n'est pas un contrôle tout simple, fait partie de ces contrôles dont le fonctionnement n'est en aucune façon standard d'un OS à l'autre.
En espérant avoir été clair, et pas trop bavard,
Gilles
Bonsoir, Gilles,
Merci pour cette longue explication, mais elle ne me convainc qu'à moitié, dans le sens où la ListView est quand même un composant universellement utilisé, dès qu'il y a des données à afficher, textes, images, en listes ou en icônes, bref tout le monde connaît ça et en 2017 on ne peut toujours pas l'utiliser à fond et correctement, je trouve ça loufoque, quoi.
Et le coup du OnSelectionChange qui ne fonctionne pas pour la TCheckListBox mais qui fonctionne pour son parent TListBox, moi je dis qu'il manque juste une bricole dans un fichier, mais je ne sais pas quoi ni où.
