Discussion :

[sioux]

Bonjour !

voila j'utilise des threads et la je "seche" sur comment communiquer avec lui...
En bref depuis le thread j'envoi des messages a la fiche qui la instanciée qui dises "voila j'en suis la" et la y pas de probleme.

Maintenant quand je veut envoyer un message au thread et bien je n'arrive pas à l'intercepter depuis le thread...
Le message est envoyé comme ceci :

Code :

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

1
2
//function SendMessage(hWnd: HWND; Msg: UINT; wParam: WPARAM; lParam: LPARAM): LRESULT;
SendMessage(MonThread.Handle,MON_MESSAGE,0,0);

Dans le thread j'ai essayé d'intercepter le message de plusieurs façon :

Code :

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

1
2
3
4
5
6
type TPersoThread = class(TThread)
                      .........
                 public
                      procedure AttrapeMessage(var msg:TMessage); message MON_MESSAGE;
                      ...........
                  end;

Et aussi dans la procedure execute en appelant des procedures comme peekmessage ou getmessage.

Bon bein voila si quelqu'un peut m'aider à résoudre ce probleme

[edam]

salut
comment tu envoit tes mesaage apartir de votre trhéde
je pense que c'est pas avec sendmessage??

pour intercepter un message utilise plutot un boolean et un string
dasn ta form

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
messag='je suis la';
b:=true;
 
dans votr trhead
    postmessage(form.handle,wm_monmessage,0,0);
while not terminate do
begin
   if b then 
     syncronise(votreproc);
   b:=false;
end ;

tt le monde va criée he c'est dangereau sa
mais non b sera ecrit par la form aprés quel recoit le message
et le tréd va lire b seulement et ne le met a false qu'aprés

[Mac LAK]

C'est normal que ça ne marche pas, tu n'utilises pas la bonne fonction... ;-)

Essaie plutôt ça pour envoyer ton message :

Code :

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

1
2
// C'est le thread ID qu'il faut utiliser, et non pas son handle.
PostThreadMessage(MonThread.ThreadID,Msg,wParam,lParam);

Et pour récupérer le message :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
While (PeekMessage(Msg,HWND(-1),0,0,PM_REMOVE)) Do
      Begin
      Case Msg.message Of
           WM_CLOSE : Exit ;
           // Insère ici tes messages "perso" à traiter. Tu peux appeler des méthodes du thread pour chaque message, notamment.
           Else Begin
                TranslateMessage(Msg);
                DispatchMessage(Msg);
                End;
           End;
      End;

N'hésites pas à regarder l'aide MSDN pour de plus amples détails sur les fonctions, OK ?
Ca devrait marcher beaucoup mieux...

[edam]

tu t'inspiré de: http://www.phidels.com/php/index.php3?page=../php/pagetelechargementzip.php3&id=336
je pense sera mieux

[Mac LAK]

tu t'inspiré de: http://www.phidels.com/php/index.php3?page=../php/pagetelechargementzip.php3&id=336
je pense sera mieux

Quel est le rapport avec la choucroute ??? Ton lien est pour les timers, pas pour les messages vers des threads !

[edam]

si regard bien

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
procedure TWaitableTime.Execute;
var
  _Event:Array [0..3] of THandle;
  _starttime:int64;
begin
  _Event[0]:=FStartEvent.Handle;
  _Event[1]:=FStopEvent.Handle;
  _Event[2]:=FTimer;
  _Event[3]:=FKillEvent.Handle;
  while not Terminated do
    begin
 
      case WaitForMultipleObjects(4,@_Event,False,INFINITE) of
        WAIT_OBJECT_0:
        WAIT_OBJECT_0+1:
        WAIT_OBJECT_0+2:
        WAIT_OBJECT_0+3:
          begin
 
            Terminate;
          end;
      end;
    end;
end;

[Mac LAK]

C'est du code pour des évènements, pas pour des messages... Les messages n'ont pas du tout la même utilité (ni le même rôle) que les évènements, voyons...

[edam]

sa je le sais mais ,c'est pas grave de donnée d'autre idée de communication avec un théad
si c'est pas avec des message en peut avec des evenement,,non??

[Mac LAK]

Ben c'eqt qu'un message possède des paramètres, ne requiert pas de variables, et en rajouter un est extrêmement facile. Notamment, ça transite facilement entre deux processus (alors entre deux threads d'un même processus, c'est encore plus facile).
Un évènement n'a pas de données associées (=gênant pour transmettre les paramètres d'un traitement), nécessitent une variable, et ne peuvent "sortir" d'un processus que s'ils sont nommés, ce qui peut être assez ennuyeux parfois.

En gros, un évènement porte bien son nom : il sert à indiquer l'existence ou pas de "quelque chose", que ce soient des données prêtes, un autre processus, etc... C'est l'équivalent d'un booléen, guère plus.
Un message possède 3 paramètres : son code (le message lui-même), une donnée 16 bits et une donnée 32 bits. Si tu as besoin de plus, tu mets un handle de mémoire partagée dans la donnée 32 bits, par exemple.

C'est très différent, et ça n'a pas du tout la même application... Même si l'on utilise très souvent les évènements pour arrêter "proprement" les threads plutôt que les messages, il est dommage d'ajouter un évènement lorsqu'il y a déjà une boucle de message dans le thread ! ;-)

[edam]

ok , merci pour l'explication, surtout moi aussi j'aime bien utilisé les message, mais a vrait dire j'ai jamis su comment envoyé un message vére un thréd ou plutot j'ai jamai eu besoi, car avec waitesingle ou waitemultipro c'est d&ja suffisant
en plus présque tout les composant que j'ai besoin utlise des tréad déja fait (comport, crono, hook key sans DLL,....)
merci dans tt les cas pour cette nouvel idée

[sioux]

bon et bien merci pour vos réponse.
j'vai modifier mon thread puis des que ca fonctionne je poste mon code.

[sioux]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
procedure TCustomClientThread.Execute;
var Msg:tagMSG;
begin
  repeat
    WaitMessage;
    while (PeekMessage(Msg,HWND(-1),0,0,PM_REMOVE)) do
    if Msg.message = CLIENT_THREAD then
    begin
      case Msg.wParam of
        CONNECTION      : PrConnection;
        DECONNECTION    : PrDeconnection;
        RECEPTION       : PrReceiveBuf;
        ENVOIE          :
          begin
            fBuf:=AllocMem(Length(PChar(Msg.lParam))+1);
            StrCopy(fBuf,PChar(Msg.lParam));
            PrSendBuf;
          end;
      end;
    end
    Else  Begin
            TranslateMessage(Msg);
            DispatchMessage(Msg);
          End;
  Until Terminated = True;
end;

la procedure terminate est appellée en cas d'erreur ou sur reception du message deconnection.

et donc en envoyant les messages avec
PostThreadMessage(thread.ThreadID,CLIENT_THREAD,CONNECTION,0);
bein ca marche ceaucoup mieux lol

[edam]

he Mac LAK c'est logique ces deux boucle imbriqué????

[Mac LAK]

he Mac LAK c'est logique ces deux boucle imbriqué????

Oui, parcequ'il y en a une pour la répétition du thread et une pour la boucle de message. Non, parceque la boucle de message ne traite pas le cas Terminated.

Je propose plutôt :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Procedure TCustomClientThread.Execute; 
var
   Msg : TMsg ; 
begin 
     While (Not Terminated) Do
           Begin 
           MsgWaitForMultipleObjects(0,NULL,FALSE,500,QS_ALLINPUT);
           While (Not Terminated) And (PeekMessage(Msg,HWND(-1),0,0,PM_REMOVE)) Do 
                 If Msg.message = CLIENT_THREAD Then 
                    Case Msg.wParam of 
                         CONNECTION   : PrConnection; 
                         DECONNECTION : PrDeconnection; 
                         RECEPTION    : PrReceiveBuf; 
                         ENVOIE       : Begin 
                                        fBuf:=AllocMem(Length(PChar(Msg.lParam))+1); 
                                        StrCopy(fBuf,PChar(Msg.lParam)); 
                                        PrSendBuf; 
                                        End; 
                    End; 
                 Else Begin 
                      TranslateMessage(Msg); 
                      DispatchMessage(Msg); 
                      End; 
           End;
End;

Le test de Terminated est à faire avec un While, plutôt : ainsi, on évite des effets de bords "amusants", comme tenter de terminer le thread par un appel à Terminate sans jamais avoir envoyé de message auparavant => le thread se bloque... De manière générale, le test de cet attribut doit être dans toutes les conditions de boucles du thread.

sioux : Tu devrais soigner un peu l'indentation de ton code, c'était pénible à lire. J'ai corrigé l'indentation, d'une part, et le type de Msg d'autre part.

Note : L'appel à WaitMessage est à éliminer si l'on veut pouvoir faire un traitement périodique sur le thread, car elle est bloquante (même si elle ne consomme pas de temps CPU). Il faut alors implémenter un message de type WAKE_UP pour "réveiller" le thread si l'on veut pouvoir effectuer un tel traitement.
J'aurais quand même tendance à privilégier la fonction MsgWaitForMultipleObjects à la place, qui permet d'implémenter un timeout. Dans ton cas précis, la valeur de retour n'a aucune importance.

Elle s'utilise ainsi :

Code :

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

MsgWaitForMultipleObjects(0,NULL,FALSE,500,QS_ALLINPUT);

A mettre en lieu et place de l'appel à WaitMessage. Dans l'exemple ci-dessus, le timeout est de 500 ms.

[sioux]

Merci pour vos préçisions !

En faite sans l'appele de WaitMessage, si le thread n'a aucune opération (IDLE) , la boucle consomme tout le temp CPU j'avai donc mis waitmessage pour bloquer le thread jusqu'a réception d'un nouveau message qui lance alors une procédure (lente) du thread...

Sinon en effet MsgWaitForMultipleObjects me parait plus adapter.
Ie:puisque aprés 500 ms on peut alors testé si terminated vaut True.


Mais sinon je suis tombé sur un os .
J'avai testé TCustomClientThread depuis une TForm donc pas de probleme de Handle pour l'envoi de message.
Le probleme c'est que j'ai voulu intégré une variable de ce type dans une classe héritée de TComponent et la il n'y a plus de Handle .
Donc mon thread ne peut plus envoyé de messages.

Donc dans un premier temps j'ai envoyé les messages (depuis le thread) au Handle de l'application. Mais la je pense que les messages ne sont pas redirigé vers ma procedure "d'interception" de ces messages.
ie :

Code :

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

procedure AttrapeMessage(var msg:TMessage); message MON_MESSAGE;

Bref je suppose que si j'utilise PeekMessage avec comme Handle celui de l'application ça devrai marché; seulement je doute qu'une boucle de réception des message dans une classe dérivée de TComponent soi une bonne idée.......

Dans le même esprit je pourrai donné le Handle du propriétaire du Tcomponent a condition qu'il soit hérité de TControl.
Précision : ce Handle dans je parle temp est stocké dans une variable privée du thread et est initialisé lors de la création du thread.

Code :

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

1
2
3
4
5
6
7
8
9
Constructor TCustomClientThread.Create(Handle : Cardinal; Adresse : PClientAdresse);
begin
 
  fHandle:=Handle;
  fAdresse:=Adresse^;
 
  inherited Create(False);
  FreeOnTerminate:=True;
end;

Enfin voila si quelqu'un peut m'aider a trouver dans quelle direction cherchée....

[Mac LAK]

En faite sans l'appele de WaitMessage, si le thread n'a aucune opération (IDLE) , la boucle consomme tout le temp CPU j'avai donc mis waitmessage pour bloquer le thread jusqu'a réception d'un nouveau message qui lance alors une procédure (lente) du thread...

C'est normal, pour qu'une boucle de message ne "crame" pas le temps CPU, il faut utiliser GetMessage... Mais cette fonction (contraîrement à PeekMessage) n'est pas adaptée à récupérer les messages de threads...

Sinon en effet MsgWaitForMultipleObjects me parait plus adapter.
Ie:puisque aprés 500 ms on peut alors testé si terminated vaut True.

C'est exactement le principe. Si ton thread doit réagir plus vite, tu mets un timeout de 100 ms, tout simplement. Cette fonction est capable de faire beaucoup plus que ça, mais pour l'usage que tu en fais, ce mode d'appel suffira amplement.

J'avai testé TCustomClientThread depuis une TForm donc pas de probleme de Handle pour l'envoi de message.
Le probleme c'est que j'ai voulu intégré une variable de ce type dans une classe héritée de TComponent et la il n'y a plus de Handle .
Donc mon thread ne peut plus envoyé de messages.

Quel besoin d'un handle ??? Les messages de threads n'ont pas besoin de handles, voyons !

Tu peux repréciser un peu ce que tu attends, stp ? Tu veux que ton thread, après avoir reçu un message, sache en renvoyer un autre en "réponse", c'est ça ?

[sioux]

arf vi c'est ça !

En faite je commande mon thread en lui envoyant des messages(donc avec PostThreadMessage).

Et mon thread envoi des messages pour dire j'en suis la, ou voila le résultat....
C'est pour ca que quand je Créé mon thread je lui passe un Handle en parametre.

[Mac LAK]

[A propos, enlève le tag "Résolu", puisque ce n'est pas encore le cas.]

Et mon thread envoi des messages pour dire j'en suis la, ou voila le résultat....

Bon, qu'as-tu besoin de faire passer comme informations dans le sens Thread->Composant ? Juste un "Coucou, j'ai démarré", ou des accusés-réception de chaque commande transmise par message, y compris une éventuelle réponse ?

C'est pour ca que quand je Créé mon thread je lui passe un Handle en parametre.

Ben oui, mais là, c'est plutôt un ThreadID qu'il faudra lui passer...

Tu me donnes les réponses aux questions ci-dessus, stp ?

[sioux]

Bon, qu'as-tu besoin de faire passer comme informations dans le sens Thread->Composant ? Juste un "Coucou, j'ai démarré", ou des accusés-réception de chaque commande transmise par message, y compris une éventuelle réponse ?

Mon thread Renvoie un "message" dans wParam et un pointeur sur un record dans lParam.
Ces messages sont envoyés pour indiqué un changement d'état, une erreur ou des données reçues.

[Mac LAK]

Mon thread Renvoie un "message" dans wParam et un pointeur sur un record dans lParam.
Ces messages sont envoyés pour indiqué un changement d'état, une erreur ou des données reçues.

Est-ce que le thread peut avoir l'initiative d'envoi d'un message, ou est-ce uniquement en réponse à un message ?

Pour les états généraux : utilise plutôt des évènements, un par état possible.

Pour tes messages : soit tu utilises également un PostThreadMessage (avec un ThreadID, donc), soit tu utilises un évènement pour signaler que la donnée est prête (elle est alors lue "thread arrêté").

Pour la boucle de messages dans ton TComponent, pas d'inquiétude : les messages destinés aux threads et ceux destinés aux windows sont différents, et ne se "mélangent" pas. C'est pour ça que tu ne peux pas intercepter les messages de threads avec les procédures classiques de Delphi.

Besoin de plus de précisions ?