1

J'ai créé une application multichilded. Les fenêtres d'application (W [n]: TMyWindows) sont toutes identiques et toutes sont associées à une instance de classe d'objet privée (E: TMyObject). Les fenêtres enfants génèrent à travers ces objets des messages. J'ai créé dans l'application principale deux threads qui traitent ces messages en fonction du contenu des messages. Par exemple permet d'avoir les appels asynchrones suivants:postthreadmessage et peekmessage problème dans delphi 2006

W[1].E.Service(thread1service) 
W[2].E.Service(thread2service) 

le TMyObject.Service (servicetype) est

case servicetype of 
    thread1service: PostThreadMessage(thread1id,...); 
    thread2service: PostThreadMessage(thread2id,...); 
end; 

Maintenant, dans la méthode d'exécution chaque thread j'ai quelque chose comme ça:

while not terminated do 
begin 
... 
if peekmessage(msg,0,thread1message_1,thread1message_n,pm_remove) then 
     process message 
do other things; 
end 

Tout va bien sauf que le deuxième thread ne reçoit aucun message. Avez-vous une idée pourquoi?

Répondre

1

Je vérifie pour m'assurer que la gamme que vous fournissez à PeekMessage() est valide. Essayez de mettre des zéros à la place de recevoir tous les messages, comme ceci:

PeekMessage(msg, 0, 0, 0, PM_REMOVE) 

Si cela ne fonctionne pas, je vérifier le résultat de la fonction PostThreadMessage() ... Il se peut que le fil n'a pas appelé PeekMessage() Pourtant, c'est ce qui incite Windows à créer la file d'attente de messages pour vous.

Comme indiqué dans this article (sous la rubrique « Remarques »), vous pouvez vérifier le résultat de l'appel à PostThreadMessage() et Sleep() si elle échoue, ou utilisez un événement pour signaler au fil conducteur que le fil de l'enfant est prêt à recevoir des messages.

HTH,

N @

0

Donc, je devais renoncer, car je ne trouve pas d'explication rationnelle.

J'ai décidé d'envoyer des messages en utilisant une section critique avec signalisation d'événement pour dire aux threads de travail qu'ils ont un message à traiter. Malheureusement, cela signifie que le thread principal doit vérifier que le thread de travail traite un message avant d'en envoyer un nouveau.

+0

Pas nécessairement. Donnez à chaque thread une file d'attente FIFO, protégée par une section critique, et ajoutez un événement à patienter.Signaler l'événement lorsque le FIFO n'est pas vide. – mghie

+0

J'ai pensé à cela, mais si le thread principal met beaucoup de massages dans la file d'attente, le thread de travail sera obligé de les traiter, et le thread de travail fait des tâches critiques dans sa boucle. Ainsi, si le thread de travail traite un message quelconque, le thread principal vide les nouveaux messages au lieu de les envoyer au thread de travail. – zoomz

+0

Triste vraiment, une file de messages de fil aurait été idéale. Je me demande toujours pourquoi ça ne marche pas pour toi. J'ai vérifié ma mise en œuvre de cela et vous ne semblez pas faire quelque chose de mal de ce que vous dites. :( – Nat

0

Je sais que c'est une vieille question, mais je viens d'avoir un problème similaire dans notre code. Nous exécutons Delphi 2006 sur Win 7 64 bits et le code en question impliquait une DLL communiquant avec une application séparée via peekmessage/postthreadmessage.

J'ai éventuellement réussi à faire remonter le problème à des droits d'administrateur accordés à l'application ou à Delphi. Le mode de compatibilité fait également apparaître le problème, car des droits d'administrateur doivent être accordés. Si des droits d'administrateur sont accordés, le thread d'administration peut communiquer avec le thread non administrateur, mais le thread non administrateur ne peut pas renvoyer un message au thread avec des privilèges d'administrateur. L'appel PostThreadMessage sur l'application non-administrateur signalait un succès, mais le message n'apparaissait jamais dans la file d'attente des messages de l'application cible.

Je n'ai pas résolu le problème, mais heureusement, j'ai réussi à exécuter l'application en mode normal, donc ce n'était pas un problème autre que le temps perdu à le poursuivre.

Questions connexes