an fait j'ai une applic en VB qui utilise 3 timers de fréquence assez basse
j'ai une interface de fenêtrage avec des boutons , cela arrive quand je
cklique sur
un bouton , le traitement associé à ce bouton se fasse avec du retard alors
que je voudrais que cela soit immédiat ?
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
X
Bonjour,
Tente de placer un :
DoEvents
-- Merci beaucoup, au revoir et à bientôt :o) ------ Site logiciels http://irolog.free.fr Mail http://irolog.free.fr/ecrire/index.htm Site perso http://irolog.free.fr/joe/index.htm Principe d'utilisation des news Groups http://support.microsoft.com/directory/worldwide/fr/newsgroup/regles.htm ------------------------------------------------------------------------------------ "Long YE-SU" a écrit dans le message de news: 44abf139$0$843$
an fait j'ai une applic en VB qui utilise 3 timers de fréquence assez basse j'ai une interface de fenêtrage avec des boutons , cela arrive quand je cklique sur un bouton , le traitement associé à ce bouton se fasse avec du retard alors que je voudrais que cela soit immédiat ?
Salutations Long YE-SU
Bonjour,
Tente de placer un :
DoEvents
--
Merci beaucoup, au revoir et à bientôt :o)
------
Site logiciels
http://irolog.free.fr
Mail
http://irolog.free.fr/ecrire/index.htm
Site perso
http://irolog.free.fr/joe/index.htm
Principe d'utilisation des news Groups
http://support.microsoft.com/directory/worldwide/fr/newsgroup/regles.htm
------------------------------------------------------------------------------------
"Long YE-SU" <ye-su@sdsi.fr> a écrit dans le message de news:
44abf139$0$843$ba4acef3@news.orange.fr...
an fait j'ai une applic en VB qui utilise 3 timers de fréquence assez
basse
j'ai une interface de fenêtrage avec des boutons , cela arrive quand je
cklique sur
un bouton , le traitement associé à ce bouton se fasse avec du retard
alors
que je voudrais que cela soit immédiat ?
-- Merci beaucoup, au revoir et à bientôt :o) ------ Site logiciels http://irolog.free.fr Mail http://irolog.free.fr/ecrire/index.htm Site perso http://irolog.free.fr/joe/index.htm Principe d'utilisation des news Groups http://support.microsoft.com/directory/worldwide/fr/newsgroup/regles.htm ------------------------------------------------------------------------------------ "Long YE-SU" a écrit dans le message de news: 44abf139$0$843$
an fait j'ai une applic en VB qui utilise 3 timers de fréquence assez basse j'ai une interface de fenêtrage avec des boutons , cela arrive quand je cklique sur un bouton , le traitement associé à ce bouton se fasse avec du retard alors que je voudrais que cela soit immédiat ?
Salutations Long YE-SU
jean-marc
"Long YE-SU" a écrit dans le message de news:44abf139$0$843$
an fait j'ai une applic en VB qui utilise 3 timers de fréquence assez
basse
j'ai une interface de fenêtrage avec des boutons , cela arrive quand
je
cklique sur un bouton , le traitement associé à ce bouton se fasse avec du retard
alors
que je voudrais que cela soit immédiat ?
Hello,
typiquement un problème de conception. Si dans un de tes timer tu effectues une opération longue ET bloquante, alors un clic sur un bouton ne sera traité qu'après la fin du traitement initié dans le timer.
Solution: 1) On ne place pas dans un timer de traitements longs 2) Au pire, on autorise les interruptions en plaçant un ou plusieurs DoEvents dans le traitement
3) Dans tous les cas, si on prévoit un traitement long et bloquant, on prévient l'utilisateur d'une façon ou d'une autre (sablier, label) et/ou on invalide explicitement les controles genre boutons jusqu'à la fin du traitement.
En tout état de cause, si on respecte 1) et 2), on ne devrait jamais en arriver à devoir appliquer 3).
C'est un cas d'école: si on arrive à devoir traiter un problème de cet ordre, cela trahit *toujours* une erreur de conception au niveau du desgign applicatif.
La vraie solution (par vraie, je veux dire pas une bidouille), c'est de repenser le design sous-jacent afin non pas de résoudre un problème qui n'a pas lieu d'être mais plutôt d'éviter le sus-dit problème.
-- Jean-marc Tester mon serveur (VB6) => http://myjmnhome.dyndns.org "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
"Long YE-SU" <ye-su@sdsi.fr> a écrit dans le message de
news:44abf139$0$843$ba4acef3@news.orange.fr...
an fait j'ai une applic en VB qui utilise 3 timers de fréquence assez
basse
j'ai une interface de fenêtrage avec des boutons , cela arrive quand
je
cklique sur
un bouton , le traitement associé à ce bouton se fasse avec du retard
alors
que je voudrais que cela soit immédiat ?
Hello,
typiquement un problème de conception.
Si dans un de tes timer tu effectues une opération longue
ET bloquante, alors un clic sur un bouton ne sera traité
qu'après la fin du traitement initié dans le timer.
Solution:
1) On ne place pas dans un timer de traitements longs
2) Au pire, on autorise les interruptions en plaçant un
ou plusieurs DoEvents dans le traitement
3) Dans tous les cas, si on prévoit un traitement long
et bloquant, on prévient l'utilisateur d'une façon ou d'une
autre (sablier, label) et/ou on invalide explicitement les
controles genre boutons jusqu'à la fin du traitement.
En tout état de cause, si on respecte 1) et 2), on ne devrait
jamais en arriver à devoir appliquer 3).
C'est un cas d'école: si on arrive à devoir traiter un
problème de cet ordre, cela trahit *toujours* une erreur
de conception au niveau du desgign applicatif.
La vraie solution (par vraie, je veux dire pas une bidouille),
c'est de repenser le design sous-jacent afin non pas de résoudre
un problème qui n'a pas lieu d'être mais plutôt d'éviter le
sus-dit problème.
--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
"Long YE-SU" a écrit dans le message de news:44abf139$0$843$
an fait j'ai une applic en VB qui utilise 3 timers de fréquence assez
basse
j'ai une interface de fenêtrage avec des boutons , cela arrive quand
je
cklique sur un bouton , le traitement associé à ce bouton se fasse avec du retard
alors
que je voudrais que cela soit immédiat ?
Hello,
typiquement un problème de conception. Si dans un de tes timer tu effectues une opération longue ET bloquante, alors un clic sur un bouton ne sera traité qu'après la fin du traitement initié dans le timer.
Solution: 1) On ne place pas dans un timer de traitements longs 2) Au pire, on autorise les interruptions en plaçant un ou plusieurs DoEvents dans le traitement
3) Dans tous les cas, si on prévoit un traitement long et bloquant, on prévient l'utilisateur d'une façon ou d'une autre (sablier, label) et/ou on invalide explicitement les controles genre boutons jusqu'à la fin du traitement.
En tout état de cause, si on respecte 1) et 2), on ne devrait jamais en arriver à devoir appliquer 3).
C'est un cas d'école: si on arrive à devoir traiter un problème de cet ordre, cela trahit *toujours* une erreur de conception au niveau du desgign applicatif.
La vraie solution (par vraie, je veux dire pas une bidouille), c'est de repenser le design sous-jacent afin non pas de résoudre un problème qui n'a pas lieu d'être mais plutôt d'éviter le sus-dit problème.
-- Jean-marc Tester mon serveur (VB6) => http://myjmnhome.dyndns.org "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
Fred
Dans : news:44ac3a0e$0$32423$, jean-marc disait :
Hello,
Hello Jean-Marc,
C'est un cas d'école: si on arrive à devoir traiter un problème de cet ordre, cela trahit *toujours* une erreur de conception au niveau du desgign applicatif.
Et le threading ? Quand on l'utilise cela trahit une erreur de design ? ;-)
-- Fred http://www.cerbermail.com/?3kA6ftaCvT
Dans : news:44ac3a0e$0$32423$ba620e4c@news.skynet.be,
jean-marc disait :
Hello,
Hello Jean-Marc,
C'est un cas d'école: si on arrive à devoir traiter un
problème de cet ordre, cela trahit *toujours* une erreur
de conception au niveau du desgign applicatif.
Et le threading ? Quand on l'utilise cela trahit une erreur de design ?
;-)
C'est un cas d'école: si on arrive à devoir traiter un problème de cet ordre, cela trahit *toujours* une erreur de conception au niveau du desgign applicatif.
Et le threading ? Quand on l'utilise cela trahit une erreur de design ? ;-)
-- Fred http://www.cerbermail.com/?3kA6ftaCvT
jean-marc
"Fred" a écrit dans le message de news:
Dans : news:44ac3a0e$0$32423$, jean-marc disait :
> Hello,
Hello Jean-Marc,
> C'est un cas d'école: si on arrive à devoir traiter un > problème de cet ordre, cela trahit *toujours* une erreur > de conception au niveau du desgign applicatif.
Et le threading ? Quand on l'utilise cela trahit une erreur de design
?
Hello,
Tu fais des threads bloquants?
-- Jean-marc Tester mon serveur (VB6) => http://myjmnhome.dyndns.org "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
"Fred" <foleide@libre.france> a écrit dans le message de
news:eRqhmzLoGHA.4636@TK2MSFTNGP03.phx.gbl...
Dans : news:44ac3a0e$0$32423$ba620e4c@news.skynet.be,
jean-marc disait :
> Hello,
Hello Jean-Marc,
> C'est un cas d'école: si on arrive à devoir traiter un
> problème de cet ordre, cela trahit *toujours* une erreur
> de conception au niveau du desgign applicatif.
Et le threading ? Quand on l'utilise cela trahit une erreur de design
?
Hello,
Tu fais des threads bloquants?
--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
> C'est un cas d'école: si on arrive à devoir traiter un > problème de cet ordre, cela trahit *toujours* une erreur > de conception au niveau du desgign applicatif.
Et le threading ? Quand on l'utilise cela trahit une erreur de design
?
Hello,
Tu fais des threads bloquants?
-- Jean-marc Tester mon serveur (VB6) => http://myjmnhome.dyndns.org "There are only 10 kind of people those who understand binary and those who don't." mailto: remove '_no_spam_' ;
Fred
Dans : news:44ad9fd7$0$32418$, jean-marc disait :
"Fred" a écrit dans le message de news:
Dans : news:44ac3a0e$0$32423$, jean-marc disait :
Hello,
Hello Jean-Marc,
C'est un cas d'école: si on arrive à devoir traiter un problème de cet ordre, cela trahit *toujours* une erreur de conception au niveau du desgign applicatif.
Et le threading ? Quand on l'utilise cela trahit une erreur de design ?
Hello,
Tu fais des threads bloquants?
Non :-)
Ce que je voulais dire c'est que la problématique de Long YE-SU n'a peut-être pas de solution en programmation «classique». D'après ses posts passés, j'ai l'impression que ses projets sont plus de type industriels, avec beacoup de communication, voir même peut-être des contraintes qui s'approchent du temps réel. Supervision d'APIs (pas les APIs windows ;-) )?
-- Fred http://www.cerbermail.com/?3kA6ftaCvT
Dans : news:44ad9fd7$0$32418$ba620e4c@news.skynet.be,
jean-marc disait :
"Fred" <foleide@libre.france> a écrit dans le message de
news:eRqhmzLoGHA.4636@TK2MSFTNGP03.phx.gbl...
Dans : news:44ac3a0e$0$32423$ba620e4c@news.skynet.be,
jean-marc disait :
Hello,
Hello Jean-Marc,
C'est un cas d'école: si on arrive à devoir traiter un
problème de cet ordre, cela trahit *toujours* une erreur
de conception au niveau du desgign applicatif.
Et le threading ? Quand on l'utilise cela trahit une erreur de
design ?
Hello,
Tu fais des threads bloquants?
Non :-)
Ce que je voulais dire c'est que la problématique de Long YE-SU n'a
peut-être pas de solution en programmation «classique».
D'après ses posts passés, j'ai l'impression que ses projets sont plus de
type industriels, avec beacoup de communication, voir même peut-être des
contraintes qui s'approchent du temps réel. Supervision d'APIs (pas les
APIs windows ;-) )?
C'est un cas d'école: si on arrive à devoir traiter un problème de cet ordre, cela trahit *toujours* une erreur de conception au niveau du desgign applicatif.
Et le threading ? Quand on l'utilise cela trahit une erreur de design ?
Hello,
Tu fais des threads bloquants?
Non :-)
Ce que je voulais dire c'est que la problématique de Long YE-SU n'a peut-être pas de solution en programmation «classique». D'après ses posts passés, j'ai l'impression que ses projets sont plus de type industriels, avec beacoup de communication, voir même peut-être des contraintes qui s'approchent du temps réel. Supervision d'APIs (pas les APIs windows ;-) )?
-- Fred http://www.cerbermail.com/?3kA6ftaCvT
Long YE-SU
oui bonjour Fred,
effectivement c'est une application industriel lié à la communication vers un automate programmable SIEMENS de la série S7 en OPC SERVER.
J'ai besoin de TImer pour récuperer des données d'une carte analogique sur mon PC : temperature, deplacement , force et je trace une courbe en temps réel. La fréquence d'échantillonnage est paramètrable par l'utilisateur. donc je n'ai pas d'autre d'utiliser des Timers rapide qui stocke ces données en RAM...
je vais voir dans le sens de la conception, en fait sur mes boutons , quand je clique dessus , il faudrait que cela soit immédiat , à ce moment j'envoi une info ou une table d'info vers l'automate en communication OPC SERVER et cela prends en général un peu moins d'une seconde mais je pense que c'est lié complètement à la comm.
Merci de vos infos Long YE-SU
"Fred" a écrit dans le message de news: uc70$
Dans : news:44ad9fd7$0$32418$, jean-marc disait : > "Fred" a écrit dans le message de > news: >> Dans : news:44ac3a0e$0$32423$, >> jean-marc disait : >> >>> Hello, >> >> Hello Jean-Marc, >> >>> C'est un cas d'école: si on arrive à devoir traiter un >>> problème de cet ordre, cela trahit *toujours* une erreur >>> de conception au niveau du desgign applicatif. >> >> Et le threading ? Quand on l'utilise cela trahit une erreur de >> design ? > > Hello, > > Tu fais des threads bloquants?
Non :-)
Ce que je voulais dire c'est que la problématique de Long YE-SU n'a peut-être pas de solution en programmation «classique». D'après ses posts passés, j'ai l'impression que ses projets sont plus de type industriels, avec beacoup de communication, voir même peut-être des contraintes qui s'approchent du temps réel. Supervision d'APIs (pas les APIs windows ;-) )?
-- Fred http://www.cerbermail.com/?3kA6ftaCvT
oui bonjour Fred,
effectivement c'est une application industriel lié à la communication
vers un automate programmable SIEMENS de la série S7 en OPC SERVER.
J'ai besoin de TImer pour récuperer des données d'une carte analogique sur
mon PC : temperature, deplacement , force
et je trace une courbe en temps réel. La fréquence d'échantillonnage est
paramètrable par l'utilisateur.
donc je n'ai pas d'autre d'utiliser des Timers rapide qui stocke ces données
en RAM...
je vais voir dans le sens de la conception, en fait sur mes boutons , quand
je clique dessus , il faudrait
que cela soit immédiat , à ce moment j'envoi une info ou une table d'info
vers l'automate en communication OPC SERVER
et cela prends en général un peu moins d'une seconde mais je pense que c'est
lié complètement à la comm.
Merci de vos infos
Long YE-SU
"Fred" <foleide@libre.france> a écrit dans le message de news:
uc70$5YoGHA.524@TK2MSFTNGP05.phx.gbl...
Dans : news:44ad9fd7$0$32418$ba620e4c@news.skynet.be,
jean-marc disait :
> "Fred" <foleide@libre.france> a écrit dans le message de
> news:eRqhmzLoGHA.4636@TK2MSFTNGP03.phx.gbl...
>> Dans : news:44ac3a0e$0$32423$ba620e4c@news.skynet.be,
>> jean-marc disait :
>>
>>> Hello,
>>
>> Hello Jean-Marc,
>>
>>> C'est un cas d'école: si on arrive à devoir traiter un
>>> problème de cet ordre, cela trahit *toujours* une erreur
>>> de conception au niveau du desgign applicatif.
>>
>> Et le threading ? Quand on l'utilise cela trahit une erreur de
>> design ?
>
> Hello,
>
> Tu fais des threads bloquants?
Non :-)
Ce que je voulais dire c'est que la problématique de Long YE-SU n'a
peut-être pas de solution en programmation «classique».
D'après ses posts passés, j'ai l'impression que ses projets sont plus de
type industriels, avec beacoup de communication, voir même peut-être des
contraintes qui s'approchent du temps réel. Supervision d'APIs (pas les
APIs windows ;-) )?
effectivement c'est une application industriel lié à la communication vers un automate programmable SIEMENS de la série S7 en OPC SERVER.
J'ai besoin de TImer pour récuperer des données d'une carte analogique sur mon PC : temperature, deplacement , force et je trace une courbe en temps réel. La fréquence d'échantillonnage est paramètrable par l'utilisateur. donc je n'ai pas d'autre d'utiliser des Timers rapide qui stocke ces données en RAM...
je vais voir dans le sens de la conception, en fait sur mes boutons , quand je clique dessus , il faudrait que cela soit immédiat , à ce moment j'envoi une info ou une table d'info vers l'automate en communication OPC SERVER et cela prends en général un peu moins d'une seconde mais je pense que c'est lié complètement à la comm.
Merci de vos infos Long YE-SU
"Fred" a écrit dans le message de news: uc70$
Dans : news:44ad9fd7$0$32418$, jean-marc disait : > "Fred" a écrit dans le message de > news: >> Dans : news:44ac3a0e$0$32423$, >> jean-marc disait : >> >>> Hello, >> >> Hello Jean-Marc, >> >>> C'est un cas d'école: si on arrive à devoir traiter un >>> problème de cet ordre, cela trahit *toujours* une erreur >>> de conception au niveau du desgign applicatif. >> >> Et le threading ? Quand on l'utilise cela trahit une erreur de >> design ? > > Hello, > > Tu fais des threads bloquants?
Non :-)
Ce que je voulais dire c'est que la problématique de Long YE-SU n'a peut-être pas de solution en programmation «classique». D'après ses posts passés, j'ai l'impression que ses projets sont plus de type industriels, avec beacoup de communication, voir même peut-être des contraintes qui s'approchent du temps réel. Supervision d'APIs (pas les APIs windows ;-) )?
