Composant visuel. Comportement de Resize avec ProcessMessage

Bonjour, à tous. Petites questions :

- Est-ce normal que la procedure Resize de composants visuels (hérités de TCustomControl) soit appelée à chaque appel de Application.ProcessMessage. Alors qu'il n'y a aucun changement de taille du composant lui même ou de la fenêtre qui le contient, d'aucunes manières ?

- Si oui ou non, est que la procedure Invalidate appel ( à un moment ou un autre) Resize (ou une des procedures qui va avec) ?

Pourquoi toutes ces questions. Lors du chargement d'une image j'appel un évènement "OnProgress" (je vous laisse deviner pourquoi faire). Qui appel à chaque ligne de l'image lue Application.ProcessMessage afin que mon TProgressBar avance. Du coup cet appel réduit considérablement les performances. Imaginez un image de plus de 3000 pixel en hauteur. Chaque appel de Resize appel Invalidate qui lui même appel Paint et tout le bazar dedans. Pourquoi ? pour rien.:pleure:

Et j'ai ainsi remarqué grâce à des "logs", ce comportement qui ne devrai pas se produire normalement, non ? (Resize c'est bien quand la taille change, non ?).

PS : C'est juste pour savoir, car j'ai déja contourné le problème.

A+

Bonjour,
Je te suggère dans un premier temps de n'appeler la modification de la barre de progression que toutes les x lignes.
Ou bien de tenter un ProgressBar.Repaint à chaque fois, et un ProcessMessages de temps en temps seulement, pour que l'appli réagisse.
Mais je n'ai pas d'explication sur l'appel du Resize.

Citation:

---

Envoyé par tourlourou

Bonjour,
Je te suggère dans un premier temps de n'appeler la modification de la barre de progression que toutes les x lignes.
Ou bien de tenter un ProgressBar.Repaint à chaque fois, et un ProcessMessages de temps en temps seulement, pour que l'appli réagisse.

---

Bonjour,
Toutes les x lignes c'est ce que j'avais fait (tous les 10%) mais idem sur une grande image, le nombre d'appel est beaucoup trop important.
Je n'avais pas pensé a "Repaint". 8-)

Citation:

---

Envoyé par tourlourou

Mais je n'ai pas d'explication sur l'appel du Resize.

---

Dommage Sous Delphi ce comportement est-il identique ou pas ?

J'ai jeté un oeil vite fait dans la LCL, je suis remonté jusqu'a TWidgetxxx sans rien remarqué de spécial. C'est dur de remonter un code complexe, dans lequel on n'a pas écrit une seule ligne.

Citation:

---

- Si oui ou non, est que la procedure Invalidate appel ( à un moment ou un autre) Resize (ou une des procedures qui va avec) ?

---

En fait c'est Resize qui appel Invalidate, comme je l'avais noté précédemment. (après cette question en plus :oops:)

Comme je l'avais dis j'ai contourné par le biais d'une variable booléenne dans ma procedure Paint.

Cela serai quand même bon de savoir si ce comportement est "Normal" afin de faire remonter l'info à l'équipe de Lazarus, le cas échéant. Pour moi il n'est pas logique.

Merci

Bonjour à tous, alors voila j'ai trouvé, j'ai jeté un oeil dans les les sources de la LCL afin de comprendre. Et j'y ai découvert la propriété en lecture seule "IsResizing" (dans TWinControl)
La LCL utilise un systeme optimisé pour le rafraichissement des compos visuel afin de limiter les appels à "Invalidate et Paint"

Donc voila si vous désirez comme moi réaliser un petit compo graphique descendant de TCustomControl et que vous ayez besoin de surcharger la procedure Resize. Alors ce petit "IsResizing" permet de savoir si oui ou non les dimensions du "controle" ont changé.

Pas besoin d'appeler"Invalidate ou paint" :

Code:

---

1 2 3 4 5 6 7 8 9 10

procedure TGLZCustomImageView.Resize; begin if not(IsResizing) then begin FBackBuffer.SetSize(ClientWidth,ClientHeight); If Transparent then BackBuffer.Clear(clrTransparent) else BackBuffer.Clear(ColorToGLZColor(Color)); end; Inherited Resize; end;

---

A+

EDIT : Oups, :oops: je suis allé un peu trop vite en besogne. Pour faire ce que je souhaite il faut que je passe par :

Code:

---

1 2 3 4 5 6 7

procedure TGLZCustomImageView.ChangeBounds(ALeft, ATop, AWidth, AHeight: integer; KeepBase: boolean); begin FBackBuffer.SetSize(ClientWidth,ClientHeight); If Transparent then BackBuffer.Clear(clrTransparent) else BackBuffer.Clear(ColorToGLZColor(Color)); // FNeededUpdate := True; inherited ChangeBounds(ALeft, ATop, AWidth, AHeight, KeepBase); end;

---

Citation:

---

Envoyé par BeanzMaster

Alors ce petit "IsResizing" permet de savoir si oui ou non les dimensions du "contrôle" ont changé.

---

Salut,

t'es sûr de ton coup, là ?

Parce qu'en termes de traduction, j'émets un doute, surtout si je compare avec l'événement OnChanging du TPageControl par exemple : l'aide (oui, "l'aide", je sais, je sais ;)...) dit

Citation:

---

OnChanging - event handler while Tab is changing

---

du coup je comprendrais IsResizing comme

Citation:

---

event handler while component is resizing

---

, en cours de redimensionnement, quoi.

Teste bien dans tous les sens, :P

Citation:

---

Envoyé par Jipété

Salut,

t'es sûr de ton coup, là ?

Parce qu'en termes de traduction, j'émets un doute, surtout si je compare avec l'événement OnChanging du TPageControl par exemple : l'aide (oui, "l'aide", je sais, je sais ;)...) dit du coup je comprendrais IsResizing comme , en cours de redimensionnement, quoi.

Teste bien dans tous les sens, :P

---

Salut c'est bien ça, tu as raison, je m'étais mépris. Mais alors pourquoi lorsque je surcharge la procedure Resize celui ci est à False ? Là je comprend pas bien. On est toujours entrain de "redimensionner" le "control". Un comportement normal voudrais que IsResizing soit à TRUE, non ?
Je n'ai pas regardé ou exactement et quand IsResizing est définie, et même si elle l'ai d'ailleurs.
C'est pourquoi j'ai rédité mon post :zoubi: après avoir regardé dans une de mes vieux code (le Panel dans les compos que j'avais posté ici, dans le forum il y a quelques temps déja).