Discussion :

[peter27x]

Hello,

EDIT : reformulation pour aller droit au coeur de problème : pour quelles raisons d'après vous, l'évènement paint d'un objet graphique peut ne pas être appelé lorsque qu'un autre objet le survole ?


message initial:

savez vous dans quels cas un objet de la classe TGraphicControl basique (simple canvas.rectangle dans son paint par exemple), peut se redessiner automatiquement lorsqu'une fenêtre d'une autre application (l'explorateur par exemple) passe au dessus de lui, et pour un autre object tout aussi simple ne pas se redessiner ?

Sachant que le AOwner des deux objets serait le même (un TPanel tout bête) et attribué de la même manière dans le create (==> AOwner).

Merci !

EDIT: en image !!

1) tout va bien... mais l'explorateur windows s'approche dangereusement...





2) ha j'en étais sûr, il est venu se coller sur mon appli !!




3) il repart, mais... damned !! Mes deux TGraphicControl ne se redessinent pas automatiquement de la même manière à un même évènement ! Il manque un bout du trait !!

[Linkin]

Je crois que c'est la différence entre un TWinControl et un TGraphicControl.

[peter27x]

Je crois que c'est la différence entre un TWinControl et un TGraphicControl.

Heu.... non, c'est pas le sujet, j'ai deux TGraphicControls, l'un se met à jour, l'autre pas, ils sont pareils de chez pareils... et leur aowner est un même TWinControl, en l'occurence un TPanel...

[Linkin]

J'avais mal compris l'énoncé .

De quel composant ces TGraphicControl héritent?

[peter27x]

J'avais mal compris l'énoncé .

De quel composant ces TGraphicControl héritent?

C'est une classe de base !

[Franck SORIANO]

En fait, ça dépend un peu de l'humeur de Windows...

Un composant se dessine lorsqu'il traitement le message WM_PAINT que lui envoie Windows.
Lorsque tu "survoles" un composant avec un autre tu peux avoir différents cas de figure : Soit windows a conservé un bitmap du composant et le redessine directement, sans déclencher de WM_PAINT, soit si ce n'est pas le cas, windows va invalider la zone qui a été effacée et poster un message WM_PAINT à la fenêtre concernée.
Ensuite, il faudra attendre que l'appli traite le message pour demander au composant de se redessiner.

Il est difficile de te répondre plus précisément sans savoir ce que tu fais dans l'appli, comme son codés les composants...
Il se peut qu'il y en ait un en double-buffered et pas l'autre, que l'appli soit occupé et ne traite pas les messages...

[peter27x]

En fait, ça dépend un peu de l'humeur de Windows...

Un composant se dessine lorsqu'il traitement le message WM_PAINT que lui envoie Windows.
Lorsque tu "survoles" un composant avec un autre tu peux avoir différents cas de figure : Soit windows a conservé un bitmap du composant et le redessine directement, sans déclencher de WM_PAINT, soit si ce n'est pas le cas, windows va invalider la zone qui a été effacée et poster un message WM_PAINT à la fenêtre concernée.
Ensuite, il faudra attendre que l'appli traite le message pour demander au composant de se redessiner.

Il est difficile de te répondre plus précisément sans savoir ce que tu fais dans l'appli, comme son codés les composants...
Il se peut qu'il y en ait un en double-buffered et pas l'autre, que l'appli soit occupé et ne traite pas les messages...

En fait j'ai mis des espions dans les paint des deux composants, celui qui se redessine tout le temps, ben le paint est appelé tout le temps, l'autre absolument jamais... C'est désespérant des cas pareils.

[Just-Soft]

En fait, ça dépend un peu de l'humeur de Windows...

Un composant se dessine lorsqu'il traitement le message WM_PAINT que lui envoie Windows.
Lorsque tu "survoles" un composant avec un autre tu peux avoir différents cas de figure : Soit windows a conservé un bitmap du composant et le redessine directement, sans déclencher de WM_PAINT, soit si ce n'est pas le cas, windows va invalider la zone qui a été effacée et poster un message WM_PAINT à la fenêtre concernée.
Ensuite, il faudra attendre que l'appli traite le message pour demander au composant de se redessiner.

Il est difficile de te répondre plus précisément sans savoir ce que tu fais dans l'appli, comme son codés les composants...
Il se peut qu'il y en ait un en double-buffered et pas l'autre, que l'appli soit occupé et ne traite pas les messages...

j'avais tout le temps cru que windows traité tout les messages ! ou plutôt disons que je n'ai pas saisie le premier passage de la réponse de maître Franck SORIANO .

[Linkin]

C'est une classe de base !

Bien sûr, mais le composant que tu utilises, non. Donc soit tu as codé des parties toi-même directement soit tu es parti d'un descendant de TGraphicControl.

Dans le premier cas, il faut absolument le code, dans le seond, on pouvait tester sans.

[peter27x]

Bien sûr, mais le composant que tu utilises, non. Donc soit tu as codé des parties toi-même directement soit tu es parti d'un descendant de TGraphicControl.

Dans le premier cas, il faut absolument le code, dans le seond, on pouvait tester sans.

J'ai viré la classe en question !

Je bosse désormais directement avec TGraphicControl et me contente de surcharger le paint... c'est plus cool comme ça... piouuuufff....

[peter27x]

J'ai mis en image le pb dans le sujet de la file !

[Linkin]

Sur un exemple simple (2 classes: rectangle, ligne avec chiffre), je n'arrive pas à reproduire le problème.

Je mets le code de dessin (basique) que j'ai mis pour afficher la ligne.

Code :

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

1
2
3
4
5
6
 
  inherited;
  Canvas.MoveTo(0,0);
  Canvas.LineTo(Width,Height);
 
  Canvas.TextOut(Width div 2, Height div 2, '1');

Il y a sûrement une interférence entre deux codes. Donc pour pouvoir aller plus loin, il faudrait je pense au moins le code de l'affichage de l'objet ligne.

[peter27x]

Sur un exemple simple (2 classes: rectangle, ligne avec chiffre), je n'arrive pas à reproduire le problème.

Je mets le code de dessin (basique) que j'ai mis pour afficher la ligne.

Code :

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

1
2
3
4
5
6
 
  inherited;
  Canvas.MoveTo(0,0);
  Canvas.LineTo(Width,Height);
 
  Canvas.TextOut(Width div 2, Height div 2, '1');

Il y a sûrement une interférence entre deux codes. Donc pour pouvoir aller plus loin, il faudrait je pense au moins le code de l'affichage de l'objet ligne.

Il ne passe même pas dans mon paint !!

Et mettre le code, le code de quoi ? Du paint ? Inutile il passe même pas dedans !

Côté appelant, mettre quoi ? J'ai 40.000 lignes de code !!

[Linkin]

Quand un Paint n'est pas appelé c'est que normalement un autre composant "opaque" cache ce composant.

Mais ce n'est pas cohérent, dans ce cas, il ne devrait pas être affiché la première fois.

[peter27x]

Quand un Paint n'est pas appelé c'est que normalement un autre composant "opaque" cache ce composant.

Mais ce n'est pas cohérent, dans ce cas, il ne devrait pas être affiché la première fois.

Haaa ! Ca se rapproche d'une des pistes que j'ai en tête, car en fait le trait que l'on voit n'est pas "entier", il part du centre des deux dessins de style "maisonnette", et est "en dessous"... hum hum hum... bon de toute façon le pb n'est ni très grave, ni bloquant...

[peter27x]

Bon, ça a l'air d'être ça, j'ai changé les coordonnées du trait, je l'ai fait tout petit dans un coin de l'écran, et là le paint est bien invoqué !

Voilà, simple histoire de guerres de territoires inter TGraphicControls... Pas glop.

EDIT : FAUX !!!! Le pb venait du fait qu'à certaines conditions le TGraphiccontrol.visible était positionné à false... mais que malgré le fait que celui ci affichait ensuite le trait de son canvas, il était en réalité toujours à visible=false ! D'où absence d'invocation du paint ! Le visible n'était jamais remis à true, mais pourtant il s'affichait bien !!

[Linkin]

Bon courage pour la suite! (vu qu'apparemment tu reprends du code, on a des fois de sacrées surprises)

[peter27x]

Bon courage pour la suite! (vu qu'apparemment tu reprends du code, on a des fois de sacrées surprises)

Non, non, je sais reconnaitre mes erreurs et pas les reporter en permanence sur du "vieux" code, cette partie là c'était du "moi" à 100%... mea culpa...