Application <=> DLL (Thread ?)

Bonjour,

J'ai créé une routine de recherche dans une DLL avec delphi7.
Elle fonctionne bien mais peut prendre jusqu'à 20 secondes avant de rendre la main au programme (ce qui est normal vu le type de recherche).
Le programme quant à lui, affiche des objets graphiques qui ont besoin d'un minimum de rafraichissement(l'exe n'est pas forcément en delphi).
Lorsque j'appelle la routine de recherche une partie de mon affichage est altéré et je dois attendre la fin du processus.

Y a t-il une solution que je pourrai implémenter au niveau DLL ? Car au niveau programme c'est plus ardu de devoir passer tous les langages en revue.

En partant d'un exemple simple d'une boucle While() dans une DLL.

merci pour vos réponses appréciées.

deux solutions

1) la méthode est non bloquante, elle lance un Thread...et il faut alors prévoir une méthode pour informer de la fin du traitement

2) la méthode invoque une fonction callback lorsqu'elle veux laisser la main à l'exe

je dis peut-etre une betise mais si ta boucle while est rapide, elle monopolyse un max de ressources.

AMHA ta dll peut déjà être assimilée a bas niveau à un thread séparé.

Peut etre en mettant un application.ProcessMessages dans la boucle pour redonner du temps a windows?

Bon je ne suis pas sur dans une dll...

C'est a tester...

petit edit pour la forme:

Dans une application (dans une dll je ne sais pas mais bon c'est un PE comme les autres) la boucle infinie suivante:

Code:

---

1 2	while true do begin end;

---

bloque l'ordinateur

tandis que la boucle infinie suivante

Code:

---

1 2	while true do begin application.ProcessMessages end;

---

rend suffisement la main a windows pour qu'il continue a traiter des messages.

A faire confirmer ou infirmer par les specialistes du forum.

Application.ProcessMessage n'est pas autorisé dans une DLL que je sache.

Ma DLL utilise une fonction récursive pour la recherche.

Pour ce qui est du callback, si je l'appelle au sein de la fonction récursive de façon périodique est-ce cela pourrait aider ou bien ce n'est vraiment pas la bonne solution ?

Mes contraintes sont les langages des programmes exe.
Delphi, Realbasic,Vb6,VbExpress, etc...

J'ai l'obligation de faire une DLL pour ainsi dire universelle.

Citation:

---

Envoyé par Steff2

Application.ProcessMessage n'est pas autorisé dans une DLL que je sache.

Ma DLL utilise une fonction récursive pour la recherche.

Pour ce qui est du callback, si je l'appelle au sein de la fonction récursive de façon périodique est-ce cela pourrait aider ou bien ce n'est vraiment pas la bonne solution ?

Mes contraintes sont les langages des programmes exe.
Delphi, Realbasic,Vb6,VbExpress, etc...

J'ai l'obligation de faire une DLL pour ainsi dire universelle.

---

Bahhh pour la dll, si tu mets forms dans les uses tu peux utiliser le Application.ProcessMessage mais j'avoues ne pas l'avoir tester, et il me semble que c'est une solution un peu cracra...

Qui aura néanmoins l'avantage d'etre facilement implementable pour un prototypage rapide.

Mais je le repette je ne sais pas ce que va donner le resultat.

En fait je n'ai jamais éssayé.

Citation:

---

Envoyé par Steff2

Ma DLL utilise une fonction récursive pour la recherche.

---

si tu peux faire en sorte que la fonction puisse être appelée en boucle au lieu de boucler elle même, tu as une solution.

un peu sur le modèle du FindFirst/FindNext mais avec un InitProc et StepProc

voici comment serait appelée la DLL depuis Delphi par exemple

Code:

---

1 2 3 4

if InitProc then begin while StepProc do Application.ProcessMessages; end;

---

Le résultat avec application.ProcessMessage n'est pas concluant.

J'ai essayé avec un callback.
Cela permet à l'exe de reprendre la main.

Mais voilà, passé une cinquantaine de retour de fonction l'application ne répond plus jusqu'à ce que la DLL ait fini son travail.

Zut de zut... pas moyen. Je ne vois pas comment améliorer la situation.

J'opterais pour la version Threadé a ta place.

oui je pense,

mais je ne peux pas toucher à l'exe car en Visualbasic le thread n'est pas vraiment efficace.
est-il possible que je crée le thread dans la dll ?
Peut-être une classe thread ?

Idée non testée :

Envoyer le handle de la fenêtre principale de l'exe comme paramètre à la dll : ça suppose seulement de modifier un peu les appels côté exécutable, et à la limite ça peut être considéré comme facultatif, si l'on accepte une valeur nulle.

Ensuite, côté DLL, envoyer à intervalle régulier quelque vaillant WM_PAINT au handle qui aura été aimablement fourni par l'exécutable, s'il est non nul... aux utilisateurs de la dll de se dépatouiller pour envoyer un handle de fenêtre valide s'ils ne veulent pas que leur appli soit bloquée par la dll. :)

ps b^te de tout ça.
Je vais essayer et voir s'il n'y a pas trop de flip.