Discussion :

[NGeVtC87]

Bonjour

Je voudrais au niveau de ma procédure arrêter l'exécution de la succession des instructions en attendant la réception d'un message qui est envoyé par un DLL externe. Je vous donne un prototype de ce que je faire ci-dessous :

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
 
 procedure TForm1.test;
 begin
   procedure A; // Cette procédure appelle des fonctions d'une DLL. La fin de l’exécution de ces fonctions est indiquée par l'envoi d'un message WM_launch
   // Arrêt et attente de la réception du message
  procedure B; 
 end;
 
 procedure TForm1.DefaultHandler(var Message);
begin
  if TMessage(Message).Msg = WM_Launch then
  begin
    // Envoyer un signal indiquant la reprise de la procédure test
  end;
end;

J'ai vu qu'avec le TEvent on pouvait gérer la réception des événements et, d'après la doc, ça me paraît assez simple à mettre en place. Par contre, je suis pas sûr que ça soit la solution pour provoquer l’arrêt et l'attente de ma procédure test.

Pensez vous que ça soit la bonne solution ou est-ce que vous proposez une autre solution ?

Merci

[SergioMaster]

Bonjour,

Avez vous songé aux threads ?
Toutefois, avant d'en donner plus, les nouvelles versions de Delphi proposant différents types de thread il me/nous faudrait connaitre la version utilisée

[Andnotor]

Le problème est que TEvent est bloquant, l'application ne pourra jamais traiter le message censé le libérer.

Pourquoi ne pas simplement exécuter "B" à la réception du message ?

[NGeVtC87]

Merci pour vos réponses.

@SergioMaster, la version c'est un de mes problème, j'utilise une ancienne version Delphi2005 mais de tout façon les thread se gère bien avec cette version. Par contre dans mon problème comme je suis dans le thread principal, il faudrait que je l’arrête comme même pour attendre le signal de la réception de mon message.

@Andnotor, j'ai donné juste un schéma de mon programme pour par trop embrouillé les lecteurs. mais ma procédure test est une procédure qui gère un manage un message qui a été émit par une autre DLL. Je dois donc donner une réponse à cette DLL "Msg.Result". et bien sur cette réponse dépend de la réception du message WM_launch. Dans le cas que je présente après l'exécution de la procédure A le programme passe directement à la procédure B et termine le process avant l'arrivée d mon message.

J'avais pensé à faire des envoie d'un message dirigé plusieurs fois dans une boucle avec

Code :

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

1
2
3
4
5
 
 
  Repeat
    value := SendMessage(fhandle,WM_msgTest,0,0)
  until value = -1;

"value" serait modifiée à la réception du message WM_launch mais je trouve ça très laid comme programmation. Vous en pensez quoi?

Merci

[Andnotor]

SendMessage est aussi bloquant ! Est-ce qu'il est émis par un thread secondaire ?

Je comprends bien ce que tu aimerais faire mais pas ta façon de procéder.
Es-tu l'auteur de cette bibliothèque ?
Est-elle thread-ées ?

Si oui tu en es l'auteur et non la DLL ne lance aucun thread secondaire, "A" devrait être une fonction retournant le résultat.
Si oui tu en es l'auteur et oui la DLL lance un thread secondaire depuis "A", un TEvent devrait être reset-é dans "A" et set-té à la fin du thread secondaire, "A" attendant que cet Event soit signalé avant de retourner.

Si tu n'est pas l'auteur de cette DLL et doit obligatoirement attendre sur ce message, je lancerais "B" à la réception de ce message (comme déjà dit).
Si tu dois obligatoirement mettre en pause cette procédure, pas de miracle, il faut un thread secondaire. Soit pour y déporter la procédure "Test" ou à l'inverse comme récepteur du message (ce qui implique une fenêtre et une boucle de messages dans ce thread). Avec bien sûr un TEvent pour synchroniser tout cela.

[retwas]

Tu peux essayer avec les TTask de l'unité System.Threading.

Code :

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

1
2
3
4
5
6
7
FutureString := TTask.Future<string>(function : string
                                     begin
                                        Sleep(3000);
                                        Result := 'Mon message';
                                     end);
 
Memo1.Lines.Add(FutureString.Value);

L'appel à Value va bloquer l'application tant que la valeur n'est pas calculé.

[Bloon]

Bonjour,

Et du côté de Application.ProcessMessages ? un truc du style :

Code :

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

1
2
3
repeat
  Application.ProcessMessages;
until (top reçu);

Bloon

[ShaiLeTroll]

Comme l'indique Andnotor, un Thread secondaire, un WaitMessage et un PeekMessage sur WM_LAUNCH,
Dommage que ta DLL ne fonctionne pas plutôt avec un CallBack

Et via ce Thread secondaire, tu peux notifier la Main Thread pour afficher une patience, une barre de progression, un pauvre TAnimate
Il faut donner l'impression que cela fonctionne et réagit, rien n'est pire pour un utilisateur qu'une application bloque

[Paul TOTH]

de façon générale "arrêter une procédure" dans le thread principal n'est pas une bonne idée, cela conduit à une application figée que Windows pourrait proposer de tuer.

soit le code est "bloquant" et il suffit de le placer dans un Thread secondaire.

soit le code est "non-bloquant" est il suffit de mettre la suite du code dans l’événement déclenché à la fin du premier traitement.

dans les deux cas, il faut que l'interface utilisateur tienne compte du traitement en cours

une méthode simple étant de faire appel à une boite de dialogue modale cf
https://www.developpez.net/forums/d1...-tache-longue/