Discussion :

[Droïde Système7]

Bonjour

Je viens de découvrir une chose dont j'étais loin de me douter

Pour quelle raison l'évènement OnClick d'un TImage est-il aussi peu nerveux que ça ?

Voici une simple manip afin d'illustrer cela :

- Un Edit + un TImage avec picture dedans + un TButton.
- Placer ce même code en OnClick sur le TImage et sur le TButton.

Code :

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

  Edit1.Text := Edit1.Text + '1';

Cliquez aux environs de 3 hertz sur le TImage et ensuite sur le TButton...

L'évènement de TButton suit, mais celui du TImage lambine à s'en dévorer le mulot, non ?

Si vous avez une idée à quoi cela tient et surtout comment est-il possible d'y remédier, j'en serais très intéressé !

Merci de toutes vos remarques et idées.

[BuzzLeclaire]

@Droïde Système7,

Utilise plutot le MouseDown se sera beaucoup plus rapide...

Code :

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

1
2
3
4
5
procedure TForm1.Image1MouseDown(Sender: TObject; Button: TMouseButton;
  Shift: TShiftState; X, Y: Integer);
begin
 
end;

[Droïde Système7]

Buzz en effet !

Whaouuu, super, oui là ça suit les clics sans trainailler.

Le OnMouseDown plus rapide que le OnClick, fallait la connaitre celle -là

@+

[guillemouze]

je pense que la raison est que le TImage gère le dblClick, alors que le TButton non. Donc du coup 1 click sur 2 sur la TImage ne génèrera pas un OnClick mais un OnDblClick

[BuzzLeclaire]

je pense que la raison est que le TImage gère le dblClick, alors que le TButton non. Donc du coup 1 click sur 2 sur la TImage ne génèrera pas un OnClick mais un OnDblClick

Je pense pas...

La raison est que "a mon avis" le poids de l'image joue un rôle.
Lors du OnClick il doit y avoir un repaint générer apres le OnMouseUp du Onclik d'où la perte de vitesse...

Les evenements du Onclik sont :
OnMouseDown
OnMouseup
OnClick

Les evenements du OnDblClik sont :
OnMouseDown
OnMouseup
OnClick
OnMouseDown
OnMouseup
OnDblClick

[Paul TOTH]

pourquoi un repaint ?!

[guillemouze]

Je pense pas...

La raison est que "a mon avis" le poids de l'image joue un rôle.
Lors du OnClick il doit y avoir un repaint générer apres le OnMouseUp du Onclik d'où la perte de vitesse...

Les evenements du Onclik sont :
OnMouseDown
OnMouseup
OnClick

Donc, si je suis ton raisonement, on a
OnMouseDown
OnMouseUp
Paint
OnClick
OnMouseDown
...

alors pourquoi le 2eme OnMouseDown ne serait pas affécté ?
De toutes facon ca me semble invraisemblable qu'il y ait un paint genéré ( et d'autant plus uniquement par le click et pas le mouseDown) !!!

[BuzzLeclaire]

pourquoi un repaint ?!

En partant de
"La raison est que "a mon avis" le poids de l'image joue un rôle. "

J'en est déduit que :
"...il doit y avoir un repaint générer apres le OnMouseUp ..."

J'aurais du dire "...il doit y avoir un truc du genre repaint... " Ou quelque chose d'autre...

Désolé, je dois revoir mes si alors sinon ...

buzz....

[Paul TOTH]

En partant de
"La raison est que "a mon avis" le poids de l'image joue un rôle. "

J'en est déduit que :
"...il doit y avoir un repaint générer apres le OnMouseUp ..."

J'aurais du dire "...il doit y avoir un truc du genre repaint... " Ou quelque chose d'autre...

Désolé, je dois revoir mes si alors sinon ...

buzz....

ben l'hypothèse de départ (poids de l'image) te viens d'où aussi ?

le coup du double click me parait plus juste (sans avoir vérifié)

[BuzzLeclaire]

Je viens de m'amuser a faire le test

voilà de quoi je pars :
Onlick

Code :

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

1
2
3
4
procedure TForm1.Image1Click(Sender: TObject);
begin
  Edit1.Text := Edit1.Text + ' Click ';
end;

DblClick

Code :

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

1
2
3
4
procedure TForm1.Image1DblClick(Sender: TObject);
begin
  edit1.Text := Edit1.Text+' Dbl '
end;

Down

Code :

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

1
2
3
4
5
procedure TForm1.Image1MouseDown(Sender: TObject; Button: TMouseButton;
  Shift: TShiftState; X, Y: Integer);
begin
  edit1.Text := Edit1.Text+' Down '
end;

UP

Code :

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

1
2
3
4
5
procedure TForm1.Image1MouseUp(Sender: TObject; Button: TMouseButton;
  Shift: TShiftState; X, Y: Integer);
begin
  edit1.Text := Edit1.Text+' UP '
end;

Si je clique 1 fois j'ai :
Down Click UP
Si je clique une 2eme fois j'ai :
Down Click UP Down Click UP
Pas d'evenement DblClick qui dans ce cas...
Si je doubleClique j'ai :
Down Click UP Dbl Down UP
La c'est normale

J'ai essayé avec une image lourde et faible pas d'écart de vitesse.

Donc si il se plaint d'une lenteur sur le OnClick, on ne sais toujours pas pourquoi c'est lent...

[Andnotor]

Le bouton est un contrôle fenêtré (avec un handle). Les messages lui sont donc directement postés.

Dans le cas d'un TImage (ou d'autres contrôles non-fenêtrés), les messages sont récupérés par la fiche qui les propage ensuite au composant concerné. D'où cette perte de temps .

[Droïde Système7]

Le poids de mon image = 3,55 Ko en BMP, pas de quoi mettre à plat le plus petit des CPU

Mais très intéressante cette discussion car franchement là je n'y aurais jamais pensé.

[guillemouze]

Le bouton est un contrôle fenêtré (avec un handle). Les messages lui sont donc directement postés.

Dans le cas d'un TImage (ou d'autres contrôles non-fenêtrés), les messages sont récupérés par la fiche qui les propage ensuite au composant concerné. D'où cette perte de temps .

Tout a fait. Mais je ne pense pas que dans notre cas, la surcharge de message de la fenetre contenante puisse ralentir significativement ceux destinés à l'image. D'autant plus que le MouseDown semble corriger le "problème", alors qu'il est traité au même titre que le click.
Je persiste à dire que certains mousedown entrainent un Click, d'autres un DblClick. Si tu compte le nombre de clicks effectifs sur la souris, et le nombre de "1" que tu obtiens dans ton edit (à 3 herts :p), tu dois pas être loin de 1/2

[Droïde Système7]

D'autant plus que le MouseDown semble corriger le "problème"

Non, ne semble pas : je confirme !

[Andnotor]

D'autant plus que le MouseDown semble corriger le "problème", alors qu'il est traité au même titre que le click.

Justement pas
Dans le cas du TImage: oui, mais pas du TButton. Le click est généré en réception d'un WM_COMMAND et non d'un WM_LBUTTONUP.

Mais je suis d'accord sur le fait que les traitements des événements souris sont identiques.

Le plus simple est de compiler avec les DCU de débuggage, de mettre un point d'arrêt dans les événements, de contrôler la pile d'appels et vous constaterez que le cheminement n'est pas identique.

Maintenant, je peux me tromper

[BuzzLeclaire]

....
Je persiste à dire que certains mousedown entrainent un Click, d'autres un DblClick. Si tu compte le nombre de clicks effectifs sur la souris, et le nombre de "1" que tu obtiens dans ton edit (à 3 herts :p), tu dois pas être loin de 1/2

Sur un développement actuel ou j'utilise à outrance le MouseDown et MouseUp, il arrive parfois que sur certain PC le Dblclik à lieu après 2 cliques cours et c'était du à la vitesse du double clique paramétré dans Windows. Mais dans les cas que j'ai traité j'ai jamais vue un événement DblClick se déclencher après 2 simples cliques disons...normal

Non, ne semble pas : je confirme !

???? ta toujours des lenteurs ?

Le bouton est un contrôle fenêtré (avec un handle). Les messages lui sont donc directement postés.

Dans le cas d'un TImage (ou d'autres contrôles non-fenêtrés), les messages sont récupérés par la fiche qui les propage ensuite au composant concerné. D'où cette perte de temps .

Bah voilà tout s'explique...