[VB6] Thread - Appel de Fonction

Le
News Free
Bonjour.

Je prends un exemple concret :
J'appelle la fonction compress de la librairie ZlibWAPI.dll
(Compression ZIP).
En même temps, le programme recois des données sur le port série.

Je sens la un problème potentiel.
Si la fonction compress prend trop de temps, je vais
louper des données reçues sur le port série/risquer un buffer overflow.


Bref l'idéal serait que l'appel de la fonction se fasse dans une
nouvelle thread et prévienne VB lorsque la compression est terminée.

Comment faire ca ?

Merci
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Sam Vimaire
Le #16360311
Il se trouve que News Free a formulé :
Bref l'idéal serait que l'appel de la fonction se fasse dans une nouvelle
thread et prévienne VB lorsque la compression est terminée.







Bon je corrige.
Je ne parle pas de Thread , ni de multi-threading en VB6

Comment faire ca


*proprement ?*
Jean-marc
Le #16360991
Sam Vimaire wrote:
Il se trouve que News Free a formulé :
Bref l'idéal serait que l'appel de la fonction se fasse dans une
nouvelle thread et prévienne VB lorsque la compression est
terminée.







Bon je corrige.
Je ne parle pas de Thread , ni de multi-threading en VB6

Comment faire ca


*proprement ?*



Hello,

si on résume, tu as finalement à réaliser 2 tâches concurrentes:
- Lecture temps réel et asynchrone sur le port série
- Exécuter une tâche bloquante (compress)

Dans ce cas, une seule solution:
La priorité doit être donnée au traitement temps réel,
c'est la contrainte la plus forte.
DONC, et c'est la seule solution, la tâche bloquante
doit être exécutée de façon détachée et concurrente.

Pas de multithreading, ce qui nous laisse comme seule solution
viable et proche la réalisation d'un petit programme autonome
pour la tâche de compress.

On lancera celui ci via Shell et on attendra tranquillement la
fin de l'exécution gracze à WaitForSingleObject, comme décrit
dans cet article de la FAQ:
http://faq.vb.free.fr/index.php?question2

Reste le problème du passage des paramètres éventuels au
programme charger du compress. Rien de bien méchant, mais à
décider en fonction de l'application.

Un truc qui marche bien et qui résoud beaucoup de problèmes:
la fonction Shell peut servir à lancer un .bat. Or un .bat est
un simple fichier texte, qu'il est très simple de générer par
programme! L'air de rien, c'est extrèmement commode !

Bonne suite;

Cordialement;


--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
Sam Vimaire
Le #16361291
Jean-marc avait prétendu :
<COUIC>
On lancera celui ci via Shell et on attendra tranquillement la
fin de l'exécution gracze à WaitForSingleObject, comme décrit
dans cet article de la FAQ:
http://faq.vb.free.fr/index.php?question2


<COUIC>
Bonne suite;




Merci beaucoup !
Jacques93
Le #16362451
Bonjour,
News Free a écrit :
Bonjour.

Je prends un exemple concret :
J'appelle la fonction compress de la librairie ZlibWAPI.dll (Compression
ZIP).
En même temps, le programme recois des données sur le port série.

Je sens la un problème potentiel.
Si la fonction compress prend trop de temps, je vais
louper des données reçues sur le port série/risquer un buffer overflow.


Bref l'idéal serait que l'appel de la fonction se fasse dans une
nouvelle thread et prévienne VB lorsque la compression est terminée.

Comment faire ca ?

Merci




Juste pour rappeler une autre possibilité, bien que la solution de
Jean-Marc soit opérationnelle : créer un exe ActiveX.

Je n'ai eu à utiliser cette méthode qu'une fois, dans un cas de figure
un peu similaire : une instruction bloquante et assez longue (Chargement
d'un fichier texte dans un contrôle Spread (Tableur)) :

Spread1.LoadTabFile


Cette instruction pouvant nécessiter plusieurs dizaines de secondes (à
l'époque) sur certains fichiers, je désirai afficher une barre de
progression indiquant l'état d'avancement. Et bien un exe ActiveX
permet, entre autre, de faire cela.

Le processus principal crée une instance de cet Exe Active, qui sera Out
Of Process, et les deux tournent chacun de leur côté, tout en pouvant
communiquer via les propriétés et méthodes de tout ActiveX. Mais je ne
vais pas faire tout un topo la dessus, vu que c'est déjà fait :-) :



Petite particularité : A la différence des autres ActiveX (Dll, Ocx),
ils ne nécessitent pas d'être enregistré par un processus tiers
(regsvr32 par exemple). Ils s'inscrivent dans le registre à leur
première exécution.

--

Cordialement,

Jacques.
Jacques93
Le #16362771
Bonjour Jean-Marc,
Jean-marc a écrit :
Sam Vimaire wrote:
Il se trouve que News Free a formulé :
Bref l'idéal serait que l'appel de la fonction se fasse dans une
nouvelle thread et prévienne VB lorsque la compression est
terminée.






Bon je corrige.
Je ne parle pas de Thread , ni de multi-threading en VB6

Comment faire ca


*proprement ?*



Hello,




Bonjour,
Préambule : je passe juste par esprit de contradiction ;-)

si on résume, tu as finalement à réaliser 2 tâches concurrentes:
- Lecture temps réel et asynchrone sur le port série
- Exécuter une tâche bloquante (compress)



J'ai compris comme ça aussi

Dans ce cas, une seule solution:
La priorité doit être donnée au traitement temps réel,
c'est la contrainte la plus forte.
DONC, et c'est la seule solution, la tâche bloquante
doit être exécutée de façon détachée et concurrente.



Jusque là, même analyse

Pas de multithreading, ce qui nous laisse comme seule solution
viable et proche la réalisation d'un petit programme autonome
pour la tâche de compress.



Et là, je dis oui mais non, c'est pas la seule solution :-p
Voir ma réponse. J'aimerai avoir ton avis :-)


--

Cordialement,

Jacques.
Jacques93
Le #16362921
Jacques93 a écrit :

[...]

Le processus principal crée une instance de cet Exe Active, qui sera Out
Of Process, et les deux tournent chacun de leur côté, tout en pouvant
communiquer via les propriétés et méthodes de tout ActiveX. Mais je ne
vais pas faire tout un topo la dessus, vu que c'est déjà fait :-) :





La documentation originale MSDN citée dans le pdf est ici :


Bonne lecture :-)

--

Cordialement,

Jacques.
Jean-marc
Le #16363561
Jacques93 wrote:

Pas de multithreading, ce qui nous laisse comme seule solution
viable et proche la réalisation d'un petit programme autonome
pour la tâche de compress.





Salut Jacques,

Et là, je dis oui mais non, c'est pas la seule solution :-p
Voir ma réponse. J'aimerai avoir ton avis :-)



Alors voila mon avis: C'est une excellente solution :-))

Je pensais en terme d'exécutables (.exe classiques), par
déformation professionnelle certainement ...

Dans ce cas de figure, un exe ActiveX comme tu l'as décrit
convient parfaitement, avec l'avantage que le problème du
passage de paramètres se résoud de façon naturelle.

PS: j'évoque rarement ces solutions car (pour le boulot) j'ai
en général toujours la contrainte de faire des solutions
portables, ce qui exclut les ActiveX... Les méthodes d'exe
séparés et de synchros de process en revanche, c'est toujours
dispo sur les plateformes sur lesquelles je développe, d'une
façon ou d'une autre...

Je fais donc mon mea culpa: la solution que je proposais n'était pas
du tout la seule, mais une parmi d'autres, la solution ActiveX
étant ici une très bonne solution (sans doute meilleure que ce que
je proposais car plus facile à maitriser).

A++ :-)

--
Jean-marc Noury (jean_marc_n2)
Microsoft MVP - Visual Basic
FAQ VB: http://faq.vb.free.fr/
mailto: remove '_no_spam_' ;
Jacques93
Le #16364041
Bonsoir Jean-marc,
Jean-marc a écrit :
Jacques93 wrote:
Pas de multithreading, ce qui nous laisse comme seule solution
viable et proche la réalisation d'un petit programme autonome
pour la tâche de compress.





Salut Jacques,

Et là, je dis oui mais non, c'est pas la seule solution :-p
Voir ma réponse. J'aimerai avoir ton avis :-)



Alors voila mon avis: C'est une excellente solution :-))

Je pensais en terme d'exécutables (.exe classiques), par
déformation professionnelle certainement ...

Dans ce cas de figure, un exe ActiveX comme tu l'as décrit
convient parfaitement, avec l'avantage que le problème du
passage de paramètres se résoud de façon naturelle.

PS: j'évoque rarement ces solutions car (pour le boulot) j'ai
en général toujours la contrainte de faire des solutions
portables, ce qui exclut les ActiveX... Les méthodes d'exe
séparés et de synchros de process en revanche, c'est toujours
dispo sur les plateformes sur lesquelles je développe, d'une
façon ou d'une autre...



J'ai aussi pratiqué ce genre d'acrobatie, multi plateformes (U...X,
X...X, A...X, DOS, OS/2 (pour tests)).

Je fais donc mon mea culpa: la solution que je proposais n'était pas
du tout la seule, mais une parmi d'autres, la solution ActiveX
étant ici une très bonne solution (sans doute meilleure que ce que
je proposais car plus facile à maitriser).

A++ :-)




Dommage que MS aie laissé tombé cette voie ...

Tu es déjà pardonné :-D

En Bretagne on est gâté en ce moment :

Motorhead hier
ZZ Top Demain si j'ai bien compris les infos

Rien que des p'tis jeunes

(Sources : FR3)

Bon Week End

--

Cordialement,

Jacques.
Publicité
Poster une réponse
Anonyme