Suite à une question qui m'est souvent posée, et que l'on voit aussi
périodiquement revenir sur ce forum, je redonne ci-dessous un exemple de
gestion des ports COM.
// Code à placer dan le code d'initialisation du projet :
GLOBAL
eNumPort, eBufferEntre, eBufferSortie, eDuree sont des entiers
bEvents est un booléen
pInitCOM()
// Code à placer dans le code de fermeture du projet :
FinTimerSys(1) // On stoppe le timer
sFerme(eNumPort) // On referme le port COM
// Procédures globales à créer selon que vous êtes en version inférieure à
WD8 ou WD8 et plus :
PROCEDURE pInitCOM()
eVitesse, eParite, eBitDonnee, eBitStop sont des entiers
bDTR, bRTS, bXON sont des booléens
// Paramètres exemples à adapter à votre cas
eNumPort = 1 // N° du port COM utilisé
eBufferEntre = 1200
eBufferSortie = 1200
eDuree = 5000
eVitesse = 9600 // Vitesse de transmission
eParite = 0 // 0 : Pas de parité, 1 : Parité paire, 2 : Parité impaire
eBitDonnee = 8 // Nombre de bits par caractère (4, 5, 6, 7 ou 8
eBitStop = 0 // 0 = 1 bit de stop, 1 = 1.5 bit de stop, 2 = 2 bits de stop
bDTR = Faux
bRTS = Faux
bXON = Faux
bEvents = Vrai // Version 8 et plus
SI PAS sOuvre(eNumPort, eBufferEntre, eBufferSortie, eDuree,bEvents) ALORS
// Version 8 ou supérieure
// sOuvre(eNumPort, eBufferEntre, eBufferSortie, eDuree) // inférieur à la
version 8
Erreur("Erreur d'ouverture du port COM : " + eNumPort)
SI PAS sFixeParamètre(eNumPort, eVitesse, eParite, eBitDonnee, eBitStop,
bDTR , bRTS , bXON) ALORS
Erreur("Erreur de paramètrage du port COM : " + eNumPort)
FIN
FIN
// Pour version 8 et supérieure
sEvénement(eNumPort,sEveCaractèreReçu, pEventCOM) // Voir dans l'aide pour
le paramètrage de cette fonction
// ou si inférieur à la version 8
// TimerSys(pTimerCOM, 500, 1)
// et pour version 8 et plus :
PROCEDURE pEventCOM()
cChaineLue est chaîne
eNbOctets est entier
cChaineLue = ""
eNbOctets = sDansFileEntrée(eNumPort)
cChaineLue = sLit(eNumPort,eNbOctets) // Pour lire la chaine contenue dans
le buffer
// A vous d'effectuer le traitement pour exploiter ensuite cette chaîne
// Pour écrire dans le buffer vous devez employer les fonctions
// sDansFileSortie(eNumPort)
// et
// sEcrit(eNumPort, cChaineaEcrire)
// ou inférieur à WD8
PROCEDURE pTimerCOM()
cChaineLue est chaîne
eNbOctets est entier
FinTimerSys(1) // on arrête le timer
cChaineLue = ""
eNbOctets = sDansFileEntrée(eNumPort)
cChaineLue = sLit(eNumPort,eNbOctets) // Pour lire la chaine contenue dans
le buffer
// A vous d'effectuer le traitement pour exploiter ensuite cette chaîne
// Pour écrire dans le buffer vous devez employer les fonctions
// sDansFileSortie(eNumPort)
// et
// sEcrit(eNumPort, cChaineaEcrire)
TimerSys(pTimerCOM, 500, 1) // On relance le timer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Francis DUHAUT
Salut,
Inutile de passer par un timer pour brancher un évenement sur la réception de donnée sur port série. En lisant la doc de windev, tu verras que l'on peut faire plus simple.
A ce qui comme moi bouffe de l'acquisition sur les ports com des PC, faite vous un protocole béton multithread.
Style j'ai un Thread qui lit, un autre qui ecrit, un autre qui traite.... Chaque thread attend l'autre par un "ThreadEnvoiSignal".
Voila. Bon dev
"Sécurité Pointage & Biométrie" a écrit dans le message de news: dna0rg$gso$
Suite à une question qui m'est souvent posée, et que l'on voit aussi périodiquement revenir sur ce forum, je redonne ci-dessous un exemple de gestion des ports COM.
// Code à placer dan le code d'initialisation du projet :
GLOBAL eNumPort, eBufferEntre, eBufferSortie, eDuree sont des entiers bEvents est un booléen
pInitCOM()
// Code à placer dans le code de fermeture du projet :
FinTimerSys(1) // On stoppe le timer sFerme(eNumPort) // On referme le port COM
// Procédures globales à créer selon que vous êtes en version inférieure à WD8 ou WD8 et plus :
PROCEDURE pInitCOM()
eVitesse, eParite, eBitDonnee, eBitStop sont des entiers bDTR, bRTS, bXON sont des booléens
// Paramètres exemples à adapter à votre cas eNumPort = 1 // N° du port COM utilisé eBufferEntre = 1200 eBufferSortie = 1200 eDuree = 5000 eVitesse = 9600 // Vitesse de transmission eParite = 0 // 0 : Pas de parité, 1 : Parité paire, 2 : Parité impaire eBitDonnee = 8 // Nombre de bits par caractère (4, 5, 6, 7 ou 8 eBitStop = 0 // 0 = 1 bit de stop, 1 = 1.5 bit de stop, 2 = 2 bits de stop bDTR = Faux bRTS = Faux bXON = Faux bEvents = Vrai // Version 8 et plus
SI PAS sOuvre(eNumPort, eBufferEntre, eBufferSortie, eDuree,bEvents) ALORS // Version 8 ou supérieure // sOuvre(eNumPort, eBufferEntre, eBufferSortie, eDuree) // inférieur à la version 8 Erreur("Erreur d'ouverture du port COM : " + eNumPort) SI PAS sFixeParamètre(eNumPort, eVitesse, eParite, eBitDonnee, eBitStop, bDTR , bRTS , bXON) ALORS Erreur("Erreur de paramètrage du port COM : " + eNumPort) FIN FIN
// Pour version 8 et supérieure sEvénement(eNumPort,sEveCaractèreReçu, pEventCOM) // Voir dans l'aide pour le paramètrage de cette fonction // ou si inférieur à la version 8 // TimerSys(pTimerCOM, 500, 1)
// et pour version 8 et plus : PROCEDURE pEventCOM()
cChaineLue est chaîne eNbOctets est entier
cChaineLue = "" eNbOctets = sDansFileEntrée(eNumPort) cChaineLue = sLit(eNumPort,eNbOctets) // Pour lire la chaine contenue dans le buffer // A vous d'effectuer le traitement pour exploiter ensuite cette chaîne
// Pour écrire dans le buffer vous devez employer les fonctions // sDansFileSortie(eNumPort) // et // sEcrit(eNumPort, cChaineaEcrire)
// ou inférieur à WD8 PROCEDURE pTimerCOM()
cChaineLue est chaîne eNbOctets est entier
FinTimerSys(1) // on arrête le timer cChaineLue = ""
eNbOctets = sDansFileEntrée(eNumPort) cChaineLue = sLit(eNumPort,eNbOctets) // Pour lire la chaine contenue dans le buffer // A vous d'effectuer le traitement pour exploiter ensuite cette chaîne
// Pour écrire dans le buffer vous devez employer les fonctions // sDansFileSortie(eNumPort) // et // sEcrit(eNumPort, cChaineaEcrire)
TimerSys(pTimerCOM, 500, 1) // On relance le timer
Sincères salutations -- Jean-Claude FLAJOULOT
Salut,
Inutile de passer par un timer pour brancher un évenement sur la réception
de donnée sur port série. En lisant la doc de windev, tu verras que l'on
peut faire plus simple.
A ce qui comme moi bouffe de l'acquisition sur les ports com des PC, faite
vous un protocole béton multithread.
Style j'ai un Thread qui lit, un autre qui ecrit, un autre qui traite....
Chaque thread attend l'autre par un "ThreadEnvoiSignal".
Voila. Bon dev
"Sécurité Pointage & Biométrie" <spetb@tiscali.fr> a écrit dans le message
de news: dna0rg$gso$1@news.tiscali.fr...
Suite à une question qui m'est souvent posée, et que l'on voit aussi
périodiquement revenir sur ce forum, je redonne ci-dessous un exemple de
gestion des ports COM.
// Code à placer dan le code d'initialisation du projet :
GLOBAL
eNumPort, eBufferEntre, eBufferSortie, eDuree sont des entiers
bEvents est un booléen
pInitCOM()
// Code à placer dans le code de fermeture du projet :
FinTimerSys(1) // On stoppe le timer
sFerme(eNumPort) // On referme le port COM
// Procédures globales à créer selon que vous êtes en version inférieure à
WD8 ou WD8 et plus :
PROCEDURE pInitCOM()
eVitesse, eParite, eBitDonnee, eBitStop sont des entiers
bDTR, bRTS, bXON sont des booléens
// Paramètres exemples à adapter à votre cas
eNumPort = 1 // N° du port COM utilisé
eBufferEntre = 1200
eBufferSortie = 1200
eDuree = 5000
eVitesse = 9600 // Vitesse de transmission
eParite = 0 // 0 : Pas de parité, 1 : Parité paire, 2 : Parité impaire
eBitDonnee = 8 // Nombre de bits par caractère (4, 5, 6, 7 ou 8
eBitStop = 0 // 0 = 1 bit de stop, 1 = 1.5 bit de stop, 2 = 2 bits de stop
bDTR = Faux
bRTS = Faux
bXON = Faux
bEvents = Vrai // Version 8 et plus
SI PAS sOuvre(eNumPort, eBufferEntre, eBufferSortie, eDuree,bEvents) ALORS
// Version 8 ou supérieure
// sOuvre(eNumPort, eBufferEntre, eBufferSortie, eDuree) // inférieur à la
version 8
Erreur("Erreur d'ouverture du port COM : " + eNumPort)
SI PAS sFixeParamètre(eNumPort, eVitesse, eParite, eBitDonnee, eBitStop,
bDTR , bRTS , bXON) ALORS
Erreur("Erreur de paramètrage du port COM : " + eNumPort)
FIN
FIN
// Pour version 8 et supérieure
sEvénement(eNumPort,sEveCaractèreReçu, pEventCOM) // Voir dans l'aide pour
le paramètrage de cette fonction
// ou si inférieur à la version 8
// TimerSys(pTimerCOM, 500, 1)
// et pour version 8 et plus :
PROCEDURE pEventCOM()
cChaineLue est chaîne
eNbOctets est entier
cChaineLue = ""
eNbOctets = sDansFileEntrée(eNumPort)
cChaineLue = sLit(eNumPort,eNbOctets) // Pour lire la chaine contenue dans
le buffer
// A vous d'effectuer le traitement pour exploiter ensuite cette chaîne
// Pour écrire dans le buffer vous devez employer les fonctions
// sDansFileSortie(eNumPort)
// et
// sEcrit(eNumPort, cChaineaEcrire)
// ou inférieur à WD8
PROCEDURE pTimerCOM()
cChaineLue est chaîne
eNbOctets est entier
FinTimerSys(1) // on arrête le timer
cChaineLue = ""
eNbOctets = sDansFileEntrée(eNumPort)
cChaineLue = sLit(eNumPort,eNbOctets) // Pour lire la chaine contenue dans
le buffer
// A vous d'effectuer le traitement pour exploiter ensuite cette chaîne
// Pour écrire dans le buffer vous devez employer les fonctions
// sDansFileSortie(eNumPort)
// et
// sEcrit(eNumPort, cChaineaEcrire)
TimerSys(pTimerCOM, 500, 1) // On relance le timer
Inutile de passer par un timer pour brancher un évenement sur la réception de donnée sur port série. En lisant la doc de windev, tu verras que l'on peut faire plus simple.
A ce qui comme moi bouffe de l'acquisition sur les ports com des PC, faite vous un protocole béton multithread.
Style j'ai un Thread qui lit, un autre qui ecrit, un autre qui traite.... Chaque thread attend l'autre par un "ThreadEnvoiSignal".
Voila. Bon dev
"Sécurité Pointage & Biométrie" a écrit dans le message de news: dna0rg$gso$
Suite à une question qui m'est souvent posée, et que l'on voit aussi périodiquement revenir sur ce forum, je redonne ci-dessous un exemple de gestion des ports COM.
// Code à placer dan le code d'initialisation du projet :
GLOBAL eNumPort, eBufferEntre, eBufferSortie, eDuree sont des entiers bEvents est un booléen
pInitCOM()
// Code à placer dans le code de fermeture du projet :
FinTimerSys(1) // On stoppe le timer sFerme(eNumPort) // On referme le port COM
// Procédures globales à créer selon que vous êtes en version inférieure à WD8 ou WD8 et plus :
PROCEDURE pInitCOM()
eVitesse, eParite, eBitDonnee, eBitStop sont des entiers bDTR, bRTS, bXON sont des booléens
// Paramètres exemples à adapter à votre cas eNumPort = 1 // N° du port COM utilisé eBufferEntre = 1200 eBufferSortie = 1200 eDuree = 5000 eVitesse = 9600 // Vitesse de transmission eParite = 0 // 0 : Pas de parité, 1 : Parité paire, 2 : Parité impaire eBitDonnee = 8 // Nombre de bits par caractère (4, 5, 6, 7 ou 8 eBitStop = 0 // 0 = 1 bit de stop, 1 = 1.5 bit de stop, 2 = 2 bits de stop bDTR = Faux bRTS = Faux bXON = Faux bEvents = Vrai // Version 8 et plus
SI PAS sOuvre(eNumPort, eBufferEntre, eBufferSortie, eDuree,bEvents) ALORS // Version 8 ou supérieure // sOuvre(eNumPort, eBufferEntre, eBufferSortie, eDuree) // inférieur à la version 8 Erreur("Erreur d'ouverture du port COM : " + eNumPort) SI PAS sFixeParamètre(eNumPort, eVitesse, eParite, eBitDonnee, eBitStop, bDTR , bRTS , bXON) ALORS Erreur("Erreur de paramètrage du port COM : " + eNumPort) FIN FIN
// Pour version 8 et supérieure sEvénement(eNumPort,sEveCaractèreReçu, pEventCOM) // Voir dans l'aide pour le paramètrage de cette fonction // ou si inférieur à la version 8 // TimerSys(pTimerCOM, 500, 1)
// et pour version 8 et plus : PROCEDURE pEventCOM()
cChaineLue est chaîne eNbOctets est entier
cChaineLue = "" eNbOctets = sDansFileEntrée(eNumPort) cChaineLue = sLit(eNumPort,eNbOctets) // Pour lire la chaine contenue dans le buffer // A vous d'effectuer le traitement pour exploiter ensuite cette chaîne
// Pour écrire dans le buffer vous devez employer les fonctions // sDansFileSortie(eNumPort) // et // sEcrit(eNumPort, cChaineaEcrire)
// ou inférieur à WD8 PROCEDURE pTimerCOM()
cChaineLue est chaîne eNbOctets est entier
FinTimerSys(1) // on arrête le timer cChaineLue = ""
eNbOctets = sDansFileEntrée(eNumPort) cChaineLue = sLit(eNumPort,eNbOctets) // Pour lire la chaine contenue dans le buffer // A vous d'effectuer le traitement pour exploiter ensuite cette chaîne
// Pour écrire dans le buffer vous devez employer les fonctions // sDansFileSortie(eNumPort) // et // sEcrit(eNumPort, cChaineaEcrire)
TimerSys(pTimerCOM, 500, 1) // On relance le timer
Sincères salutations -- Jean-Claude FLAJOULOT
Sécurité Pointage & Biométrie
"Francis DUHAUT" a écrit dans le message de news: 4398919a$0$18584$
Salut,
Inutile de passer par un timer pour brancher un évenement sur la réception de donnée sur port série. En lisant la doc de windev, tu verras que l'on peut faire plus simple.
A ce qui comme moi bouffe de l'acquisition sur les ports com des PC, faite vous un protocole béton multithread.
Style j'ai un Thread qui lit, un autre qui ecrit, un autre qui traite.... Chaque thread attend l'autre par un "ThreadEnvoiSignal".
Voila. Bon dev
Avec les version 8 et supérieures pas besoin de timer ou de thread. Par contre, sur des applications toutnant 24 H sur 24 et 365 jours par an, j'ai testé les deux solutions en 7.5 (timer et thread), et le timer m'apportait de meileurs résultats. Ceci dit, à chacun sa méthode, l'essentiel est que ça fonctionne correctement.
"Francis DUHAUT" <fduhaut@club-internet.fr> a écrit dans le message de news:
4398919a$0$18584$7a628cd7@news.club-internet.fr...
Salut,
Inutile de passer par un timer pour brancher un évenement sur la réception
de donnée sur port série. En lisant la doc de windev, tu verras que l'on
peut faire plus simple.
A ce qui comme moi bouffe de l'acquisition sur les ports com des PC, faite
vous un protocole béton multithread.
Style j'ai un Thread qui lit, un autre qui ecrit, un autre qui traite....
Chaque thread attend l'autre par un "ThreadEnvoiSignal".
Voila. Bon dev
Avec les version 8 et supérieures pas besoin de timer ou de thread.
Par contre, sur des applications toutnant 24 H sur 24 et 365 jours par an,
j'ai testé les deux solutions en 7.5 (timer et thread), et le timer
m'apportait de meileurs résultats.
Ceci dit, à chacun sa méthode, l'essentiel est que ça fonctionne
correctement.
"Francis DUHAUT" a écrit dans le message de news: 4398919a$0$18584$
Salut,
Inutile de passer par un timer pour brancher un évenement sur la réception de donnée sur port série. En lisant la doc de windev, tu verras que l'on peut faire plus simple.
A ce qui comme moi bouffe de l'acquisition sur les ports com des PC, faite vous un protocole béton multithread.
Style j'ai un Thread qui lit, un autre qui ecrit, un autre qui traite.... Chaque thread attend l'autre par un "ThreadEnvoiSignal".
Voila. Bon dev
Avec les version 8 et supérieures pas besoin de timer ou de thread. Par contre, sur des applications toutnant 24 H sur 24 et 365 jours par an, j'ai testé les deux solutions en 7.5 (timer et thread), et le timer m'apportait de meileurs résultats. Ceci dit, à chacun sa méthode, l'essentiel est que ça fonctionne correctement.
Francis DUHAUT
Bien sur chacun sa méthode.
"Sécurité Pointage & Biométrie" a écrit dans le message de news: dna4js$k2e$
"Francis DUHAUT" a écrit dans le message de news: 4398919a$0$18584$
Salut,
Inutile de passer par un timer pour brancher un évenement sur la réception de donnée sur port série. En lisant la doc de windev, tu verras que l'on peut faire plus simple.
A ce qui comme moi bouffe de l'acquisition sur les ports com des PC, faite vous un protocole béton multithread.
Style j'ai un Thread qui lit, un autre qui ecrit, un autre qui traite.... Chaque thread attend l'autre par un "ThreadEnvoiSignal".
Voila. Bon dev
Avec les version 8 et supérieures pas besoin de timer ou de thread. Par contre, sur des applications toutnant 24 H sur 24 et 365 jours par an, j'ai testé les deux solutions en 7.5 (timer et thread), et le timer m'apportait de meileurs résultats. Ceci dit, à chacun sa méthode, l'essentiel est que ça fonctionne correctement.
Bien sur chacun sa méthode.
"Sécurité Pointage & Biométrie" <spetb@tiscali.fr> a écrit dans le message
de news: dna4js$k2e$1@news.tiscali.fr...
"Francis DUHAUT" <fduhaut@club-internet.fr> a écrit dans le message de
news: 4398919a$0$18584$7a628cd7@news.club-internet.fr...
Salut,
Inutile de passer par un timer pour brancher un évenement sur la
réception de donnée sur port série. En lisant la doc de windev, tu verras
que l'on peut faire plus simple.
A ce qui comme moi bouffe de l'acquisition sur les ports com des PC,
faite vous un protocole béton multithread.
Style j'ai un Thread qui lit, un autre qui ecrit, un autre qui traite....
Chaque thread attend l'autre par un "ThreadEnvoiSignal".
Voila. Bon dev
Avec les version 8 et supérieures pas besoin de timer ou de thread.
Par contre, sur des applications toutnant 24 H sur 24 et 365 jours par an,
j'ai testé les deux solutions en 7.5 (timer et thread), et le timer
m'apportait de meileurs résultats.
Ceci dit, à chacun sa méthode, l'essentiel est que ça fonctionne
correctement.
"Sécurité Pointage & Biométrie" a écrit dans le message de news: dna4js$k2e$
"Francis DUHAUT" a écrit dans le message de news: 4398919a$0$18584$
Salut,
Inutile de passer par un timer pour brancher un évenement sur la réception de donnée sur port série. En lisant la doc de windev, tu verras que l'on peut faire plus simple.
A ce qui comme moi bouffe de l'acquisition sur les ports com des PC, faite vous un protocole béton multithread.
Style j'ai un Thread qui lit, un autre qui ecrit, un autre qui traite.... Chaque thread attend l'autre par un "ThreadEnvoiSignal".
Voila. Bon dev
Avec les version 8 et supérieures pas besoin de timer ou de thread. Par contre, sur des applications toutnant 24 H sur 24 et 365 jours par an, j'ai testé les deux solutions en 7.5 (timer et thread), et le timer m'apportait de meileurs résultats. Ceci dit, à chacun sa méthode, l'essentiel est que ça fonctionne correctement.
Francis DUHAUT
Je suis quand même étonné. Je constatais de la consomation CPU avec les timers. J'ai optimisé un protocole béton multithread et je scanne en permance sur mes port séries à 38400bds avec 1% de consomation CPU.
De plus, je trouve qu'une appli bien threadé est gage de fiabilité. Avec la version 10, on ne devrait plus se poser la question il parait. Tout sera alors automatique ! Finis le temps des bidouille...
Bonne soirée.
"Sécurité Pointage & Biométrie" a écrit dans le message de news: dna4js$k2e$
"Francis DUHAUT" a écrit dans le message de news: 4398919a$0$18584$
Salut,
Inutile de passer par un timer pour brancher un évenement sur la réception de donnée sur port série. En lisant la doc de windev, tu verras que l'on peut faire plus simple.
A ce qui comme moi bouffe de l'acquisition sur les ports com des PC, faite vous un protocole béton multithread.
Style j'ai un Thread qui lit, un autre qui ecrit, un autre qui traite.... Chaque thread attend l'autre par un "ThreadEnvoiSignal".
Voila. Bon dev
Avec les version 8 et supérieures pas besoin de timer ou de thread. Par contre, sur des applications toutnant 24 H sur 24 et 365 jours par an, j'ai testé les deux solutions en 7.5 (timer et thread), et le timer m'apportait de meileurs résultats. Ceci dit, à chacun sa méthode, l'essentiel est que ça fonctionne correctement.
Je suis quand même étonné. Je constatais de la consomation CPU avec les
timers. J'ai optimisé un protocole béton multithread et je scanne en
permance sur mes port séries à 38400bds avec 1% de consomation CPU.
De plus, je trouve qu'une appli bien threadé est gage de fiabilité. Avec la
version 10, on ne devrait plus se poser la question il parait. Tout sera
alors automatique ! Finis le temps des bidouille...
Bonne soirée.
"Sécurité Pointage & Biométrie" <spetb@tiscali.fr> a écrit dans le message
de news: dna4js$k2e$1@news.tiscali.fr...
"Francis DUHAUT" <fduhaut@club-internet.fr> a écrit dans le message de
news: 4398919a$0$18584$7a628cd7@news.club-internet.fr...
Salut,
Inutile de passer par un timer pour brancher un évenement sur la
réception de donnée sur port série. En lisant la doc de windev, tu verras
que l'on peut faire plus simple.
A ce qui comme moi bouffe de l'acquisition sur les ports com des PC,
faite vous un protocole béton multithread.
Style j'ai un Thread qui lit, un autre qui ecrit, un autre qui traite....
Chaque thread attend l'autre par un "ThreadEnvoiSignal".
Voila. Bon dev
Avec les version 8 et supérieures pas besoin de timer ou de thread.
Par contre, sur des applications toutnant 24 H sur 24 et 365 jours par an,
j'ai testé les deux solutions en 7.5 (timer et thread), et le timer
m'apportait de meileurs résultats.
Ceci dit, à chacun sa méthode, l'essentiel est que ça fonctionne
correctement.
Je suis quand même étonné. Je constatais de la consomation CPU avec les timers. J'ai optimisé un protocole béton multithread et je scanne en permance sur mes port séries à 38400bds avec 1% de consomation CPU.
De plus, je trouve qu'une appli bien threadé est gage de fiabilité. Avec la version 10, on ne devrait plus se poser la question il parait. Tout sera alors automatique ! Finis le temps des bidouille...
Bonne soirée.
"Sécurité Pointage & Biométrie" a écrit dans le message de news: dna4js$k2e$
"Francis DUHAUT" a écrit dans le message de news: 4398919a$0$18584$
Salut,
Inutile de passer par un timer pour brancher un évenement sur la réception de donnée sur port série. En lisant la doc de windev, tu verras que l'on peut faire plus simple.
A ce qui comme moi bouffe de l'acquisition sur les ports com des PC, faite vous un protocole béton multithread.
Style j'ai un Thread qui lit, un autre qui ecrit, un autre qui traite.... Chaque thread attend l'autre par un "ThreadEnvoiSignal".
Voila. Bon dev
Avec les version 8 et supérieures pas besoin de timer ou de thread. Par contre, sur des applications toutnant 24 H sur 24 et 365 jours par an, j'ai testé les deux solutions en 7.5 (timer et thread), et le timer m'apportait de meileurs résultats. Ceci dit, à chacun sa méthode, l'essentiel est que ça fonctionne correctement.
