Discussion :

[ceugniet]

Bonjour à tous.

Je suis en train d'essayer de résoudre un problème de mouvement interactif.

J'ai une image. Dans les événements de cette image j'ai défini des actions à faire lorsque j'appuie sur le bouton de ma souris (MouseDown), lorsque je la bouge (MouseMove) et lorsque je lâche le bouton (MouseUp).

Mon problème est que les événements sont trop rapidement détectés avant que j'aie fini mon boulot. Par exemple, un événement MouseMove intervient qui déclenche un bout de code, et avant que j'aie terminé ce code, un deuxième événement MouseMove se déclenche. Je voudrais bien avoir la paix tant que mon code n'est pas terminé ...

Ce n'est qu'un exemple parmi d'autres. En fait tout se mélange parce que mes événements continuent à arriver pendant que je traite les précédents, alors que je voudrais bien en faire abstraction pendant ce temps (c'est-à-dire les négliger complètement, comme s'ils n'avaient pas lieu du tout). Ce n'est pas facile à gérer : par exemple, je pourrais décider d'enregistrer dans une variable l'état dans lequel je me trouve et tester cette variable à chaque événement pour savoir si j'ai le droit de prendre la main : si oui, je donnerai à cette variable une valeur qui interdira à tout autre événement d'intervenir. Mais le problème est que je dois prévoir le cas où deux événements simultanés feraient le test en même temps et croiraient tous deux avoir le droit d'agir !!! On n'en sort pas.

Existe-t-il un moyen de bloquer l'accès à une variable. Si oui, je serai sauvé. Même si deux événements tentent de bloquer simultanément la même variable, seul l'un d'entre eux y parviendra.

Merci pour toute suggestion.

Titre modifié par Greybird
Ecrire en majuscules, c'est CRIER. Impoli donc.

[Michel Devaud]

Bonjour

Code :

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

1
2
3
4
5
6
7
void __fastcall TForm1::TrucMouseMove(...)
{
   Truc->OnMouseMove=NULL;
   // Traitement
   ...
   Truc->OnMouseMove=TrucMouseMove;
}

Cela devrait régler votre problème.

[ceugniet]

Ben oui ! J'y ai bien pensé. Mais il faudrait faire la même chose pour OnMouseUp, et OnMouseDown. Et ça n'empêchera pas, pendant ce temps, qu'une autre routine fasse de même et que tout soit quand même mélangé...

Pour Greybird,

Désolé, je ne voulais pas être impoli... Je le saurai désormais.

[Greybird]

Par exemple, un événement MouseMove intervient qui déclenche un bout de code, et avant que j'aie terminé ce code, un deuxième événement MouseMove se déclenche. Je voudrais bien avoir la paix tant que mon code n'est pas terminé ...

Les événements sont dépilés un à un.
Donc tant que tu ne fais pas de multithread, tu es sûr que tout ton code sera exécuté avant que tu passes au traitement de l'événement suivant.

[ceugniet]

Merci pour vos réponses.

Je ne suis pas d'accord avec Greybird. Je ne fais pas de multithread "sciemment" ( en ce sens que je ne sais même pas lancer un thread ! ). Par contre le "système" qui m'encadre le fait à l'évidence. Sinon, je n'aurais pas de problème. Je n'excluais pas au départ une erreur de logique de programmation, mais j'ai vérifié, à l'aide de la clock rapide QueryPerformanceCounter (il se trouve que sa fréquence est égale à la cadence de mon nouveau PC, 3GHz), que malgré que je me sois contenté de définir les actions à faire en cas de MouseDown, de MouseMove et de MouseUp en clickant sur les cases correspondantes sur l'inspecteur d'objet, il est clair que parfois je démarre l'action à faire en cas de Mousemove AVANT d'avoir terminé la précédente (action de Mouve Move). Cela signifie donc que le système prend en compte un nouveau mouvement de la souris avant que j'ai fini de traiter celui qui est en cours...

[Greybird]

Bonjour,

ceugniet, je suis désolé, mais c'est le fonctionnement de Windows de faire dépiler la pile de message un par un par la boucle de traitement de messages du programme.
Le système ne fait que rajouter l'événement dans la pile de message, que l'application dépile un par un.

Au pire, ça pourrait être du à l'hyperthreading, encore que je vois mal comment il pourrait interférer avec un programme single thread. Là je maitrise pas.

Cordialement,

Arnaud

[Nicolas]

Bonjour,

ceugniet, je suis désolé, mais c'est le fonctionnement de Windows de faire dépiler la pile de message un par un par la boucle de traitement de messages du programme.
Le système ne fait que rajouter l'événement dans la pile de message, que l'application dépile un par un.

Mis à part lors de l'usage d'un "Application->ProcessMessages()", je suis d'accord avec Greybird : un événement (OnMouseMove par exemple) est traité entièrement avant de passer au message suivant.

Nicolas

[Freeze]

t'as mis des break-point pour vérifier tes dires ?? moi aussi je suis assez sceptiques parce que j'utilise régulièrement ce genre d'évenements et c'est vrai que parfois il se passe des choses bizarres, mais en regardant de plus près, je m'apercois toujours que c'est moi qui écrit des choses bizarres ... je me demande vraiment quand Borland fera ce que je veux et pas ce que je dis ...

[ceugniet]

Greybird,

Je crois bien que c'est toi qui as raison. J'ai fait un autre test, dans un contexte plus simple que le programme sur lequel je suis en train de travailler, où je me contente de noter les heures de début et de fin des codes déclenchés par les MouseDown, MouseMove et MouseUp (dans ces trois bouts de code, je déclenche des calculs très longs, exprès). J'ai effectivement constaté qu'à aucun moment, le mélange auquel je fais allusion dans le titre ne se produisait. Comme de plus tu confirmes de façon catégorique, je n'ai plus de doute à avoir. Il faut croire donc que c'est bel et bien la logique de mon programme qui laisse à désirer.

Merci de ton aide pour cette nouvelle certitude (les certitudes sont rares pour C++ en ce qui me concerne).

Puis-je en déduire qu'il n'y a pas d'interruption ? Que les portions de code seront toujours exécutées dans l'ordre où les "click" correspondants ont eu lieu ? Quel bouleversement se produit alors si on lance l'Application-ProcessMessages() évoqué par Nicolas ?

Nicolas,

J'avais effectivement, à un moment, inséré un Application->ProcessMessages() (qui s'est révélé inutile et que j'ai enlevé par la suite) : ceci explique peut-être cela, car je ne me souviens plus entièrement de l'ordre de mes diverses démarches...

Freeze

t'as mis des break-point pour vérifier tes dires ??

Est-ce à moi que tu t'adresses ou à Greybird ? Si c'est à moi, la réponse est non : je ne peux rien analyser avec des break-points dans ce cas-là vu que le moindre mouvement de souris réduirait à néant mes volontés de suivre pas à pas le déroulement du programme ; de plus le PC réagit à la microseconde (si ce n'est plus vite) alors que moi, au mieux, c'est à la seconde !!!

Je suis malgré tout content de voir que je ne suis pas le seul infortuné. La différence entre toi et moi est que moi je n'ai pas encore compris ce qui était réellement arrivé dans mon programme.

Merci à vous tous pour ce dialogue très riche en enseignements.

[Nicolas]

Quel bouleversement se produit alors si on lance l'Application-ProcessMessages() évoqué par Nicolas ?

Nicolas,

J'avais effectivement, à un moment, inséré un Application->ProcessMessages() (qui s'est révélé inutile et que j'ai enlevé par la suite) : ceci explique peut-être cela, car je ne me souviens plus entièrement de l'ordre de mes diverses démarches...

Si on appelle "Application->ProcessMessages" dans le traitement d'un évènement (ev1), le traitement est interrompu pour que Windows traite tous ses messages en attente ==> donc on va passer dans le traitement du second événement (ev2) AVANT de terminer celui de ev1.
Ceci peut donc laisser penser que les événements sont "mélangés".

Nicolas