2010-07-01 9 views
1

J'ai une DLL avec un composant TClientSocket, elle est utilisée pour parler à une machine du système téléphonique. La DLL possède uniquement des paramètres PChar dans les méthodes d'exportation et n'utilise pas de packages.Delphi DLL - événements TClientSocket

Lorsque je charge la DLL avec l'application Delphi, tous les événements fonctionnent correctement, aucun problème jusqu'à présent. Mon client appelle cette DLL à partir d'un programme console Win32 Cobol, et le TClientSocket ne déclenche pas les événements lorsque cela se produit, il utilise une boucle principale pour appeler une méthode de vérification dans DLL pour savoir s'il y a un retour de la Système téléphonique, si elle renvoie OK puis il appelle la méthode Get, et voici où le problème se produit:

Dans l'événement TClientSocket.OnRead, j'appelle TClientSocket.Socket.ReceiveText, et il y a plusieurs retours de l'application serveur, ce faites-moi penser que l'événement est seulement déclenché quand j'appelle une méthode de DLL, et le TClientSocket tient plusieurs retours dans la mémoire tampon. Le problème est que je ne trouve pas de délimiteur pour diviser ce retour.

Comment puis-je résoudre ce problème? Est-ce que je peux ajouter quelque chose à ma DLL pour m'assurer que l'événement OnRead sera déclenché chaque fois qu'il n'est pas appelé d'un programme Delphi?

Répondre

2

vous avez probablement besoin d'une boucle de message dans votre DLL .. (Les applications de console n'ont pas de pompe de message ..). SO mettre en œuvre quelque chose comme ça dans votre constructeur dll:

var Msg : TMsg; 
    res : Integer; 

.
. .

While true Do Begin 
     res := Integer(GetMessage(Msg, 0, 0, 0)); 
     If res = -1 Then 
      Exit // error 
     else if res = 0 then 
      exit // WM_QUIT received 
     else begin 
      TranslateMessage(Msg); 
      DispatchMessage(Msg); 
     end; 
End; { While } 

Jetez un oeil à un fil similaire http://www.mofeel.net/1102-comp-lang-pascal-delphi-misc/2763.aspx

+0

Je l'ai fait dans la procédure principale DLL et la première interaction la DLL s'arrête dans GetMessage, et ne pas aller de l'avant. –

+0

Maintenant, je sais GetMessage attendre jusqu'à ce qu'il reçoive un message, donc je passe à PeekMessage, mais il renvoie -1, donc il s'éteint. si je supprime le test, il ne chargera jamais l'application. –

+0

Cesar, peut-être le coupable est l'application COBOL voir un autre fil similaire (il est. Net, mais semble avoir le même problème) http://www.devnewsgroups.net/windowsforms/t10952-messageloop-thread.aspx –

0

récemment, j'ai rencontré un problème similaire que vous, mon ClientSocket en dll fonctionne ok avec delphi-exe, mais pas avec exe c-console, et Je me suis souvenu tclientsocket utilise le mode select-event, qui a besoin du thread principal pour traiter la boucle de message, donc, si vous utilisez un tclientsocket avec le mode nonblock dans une DLL, l'hôte ne doit JAMAIS bloquer le thread principal

, et doit faire la boucle de message (par exemple, en appelant dans un programme de console).

parfois nous ne pouvons pas modifier le code hôte (le cas je rencontre), alors nous pouvons faire comme ce

socket.sendtext(); 
repeat s :=socket.recevtext; 
until timeout or length(s)>0; 

Bien sûr, vous devez vérifier si s est le paquet complet ou si.