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.
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
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 !
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 !
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 !
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 !
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
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
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)) :
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.
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)) :
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.
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)) :
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
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.
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 :-)
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
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 :-) :
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 :-) :
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 :-) :
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).
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).
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).
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.
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
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
