Voici une technique permettant d'exécuter des traitements en tâche de fond dans une application.
Démonstration: Compiler le projet ASYNC.JPX en ASYNC.EXE.(Serveur COM EXE) Puis lancer le formulaire DEMO.SCX.
Pour dé-synchroniser l'appli client du composant, le traitement est lancé par un Timer Event.
J'utilise également cette méthode pour effectuer des traitements distribués sur d'autre ordinateurs (DCOM)
On peut également faire un composant COM+, mais l'objet Timer de VFP, ne fonctionne pas dans une DLL, il faut utiliser un autre Timer (API ou ActiveX)
Code source :
DEFINECLASS async AS session OLEPUBLIC
fin = .f.&& pour indiquer que le traitement est fini
cCommande = ""&& commande
cScript=""&& script
oCaller = null&& Appelant (pour callback)
oTimer = null
cErreur =""&& Message d'erreur
PROCEDUREinit this.oTimer = NEWOBJECT("cTimer") this.oTimer.oSession = this SYS(2335,0) ONSHUTDOWNquit ENDPROC
PROCEDURE Stop DECLAREInteger SendMessage in User32 ; Long nhWnd, Integer Msg, Integer wParam, Long lParam
#DEFINE WM_CLOSE 0x10
SendMessage(_vfp.hwnd ,WM_CLOSE ,0,0) ENDPROC
ENDDEFINE
***
DEFINECLASS cTimer asTimer
enabled=.f. interval=1
oSession=null
PROCEDUREtimer IFthis.Enabled this.enabled=.f. PRIVATE oCaller
oCaller=this.oSession.oCaller LOCAL cCommande
cCommande=this.oSession.cCommande
&cCommande IFvarType(oCaller.tag)<>"C" && le prog appelant n'est plus connecté QUIT ENDIF this.oSession.fin = .t. ENDIF ENDPROC PROCEDUREerror(nError, cMethod, nLine) this.oSession.fin = .t. this.oSession.cErreur = Message() this.oSession.oCaller.on_Error(Message()) RETURNTOmaster ENDPROC
ENDDEFINE
Commentaires
le 15/12/2005, EmanuelL a écrit : Thierry, Je ne maitrise pas encore cette techno, en testant ton exemple le taux d'utilisation de mon UC est pas mal consommé, il atteint 98%, jusqu'à l'arrêt de ton exemple (Ansy.exe). Est-ce que c'est normal?
le 16/12/2005, Thierry a écrit : C'est volontaire. Cette démo simule une tâche de fond consommant un maximum de CPU (pendant 6 secondes). Tu auras peut être remarqué que pendant ce temps, tu peux faire autre chose dans VFP sans être particulièrement gêné.
le 16/12/2005, EmanuelL a écrit : Merci Thierry. Je comprends maintenant. Malgré l'occuparation CPU à 98%, j'arrive à faire autres choses sans problème.
le 08/08/2006, Luc a écrit : Bonjour Thierry. Je suis actuellement à la recherche d’une méthode pour effectuer des traitements distribués sur d’autres ordinateurs. Ton code m’intéresse donc particulièrement. J’aurais donc voulu savoir comment utiliser DCOM afin de pouvoir adapter ton code. Merci de ton attention
Luc
le 08/08/2006, Thierry a écrit : C'est essentiellement un problème de paramétrage des droits d'exécution et d'accés par le client du composant situé sur le serveur. >Démarrer>Executer>DCOMCNFG>Service de composant
Voir aussi la fonction VFP CREATEOBJECTEX() pour indiquer le serveur.
le 23/10/2006, Luc a écrit : Parfait parfait. Juste une question : comment faire pour inscrire ce composant COM sur une nouvelle machine, sans pour autant avoir à utiliser un setup compliqué. Pour faire ça avec des DLL ou des OCX, j'utilise Regsvr32, qui est parfait, mais ne prend pas en charge les exe. Y a-t-il une autre fonction Windows similaire ? Ou faut-il s'appuyer sur le fichier VBR généré par Fox, mais alors comment ? Merci d'avance Luc
le 23/10/2006, Thierry a écrit : On peut utiliser CLIREG32.EXE (livré avec d'ancienne version de VFP). Il va s'appuyer sur le .VBR ainsi qu'eventuellement le .TLB (biblio de types)
Si tu ne trouves pas CLIREG32.EXE, demandes le moi par e-mail.
le 01/11/2006, Thomas a écrit : Bonjour Thierry, lorsque j'utilise la méthode CREATEOBJECTEX() j'ai l'erreur suivante : Accés refusé. J'ai fait le test en désactivant les firewalls. Une idée ?
Thierry,
Je ne maitrise pas encore cette techno, en testant ton exemple le taux d'utilisation de mon UC est pas mal consommé, il atteint 98%, jusqu'à l'arrêt de ton exemple (Ansy.exe).
Est-ce que c'est normal?