Dans un programme C++ en mode console (fonction main) je dois lancer un
timer (SetTimer) et rien d'autre. Mais il ne faut pas que je sorte du main.
Venant du monde VB, je ferais en VB :
bOK = false
hTimer = SetTimer(0, 0, delay, TimerProc)
While(not bOK) if GetInputState Then DoEvents 'pour pas bloquer
KillTimer hTimer
Sachant que c'est la procédure TimerProc qui mettera à true bOK et donc
mettra fin au programme.
En C++ le programme est quasiment le meme, sauf que je ne sais pas
reproduire le comportement de la ligne :
"if GetInputState then DoEvents"
> ça me dérange ta boucle while(!bOk). > c'est de l'attente active. > c'est pourri et inutile.
donc tu préconises la méthode de Møgluglu ?
Non, il parle de ton code VB. Le DoEvents de VB retourne immédiatement s'il n'y a rien à faire, et tu vas donc consommer beaucoup de CPU dans ta boucle. La fonction GetMessage de Win32 est différente, elle est bloquante tant qu'il n'y a pas de message et tu ne vas donc pas consommer de CPU quand tu seras dedans.
PurL a écrit :
Ambassadeur Kosh wrote:
> ça me dérange ta boucle while(!bOk).
> c'est de l'attente active.
> c'est pourri et inutile.
donc tu préconises la méthode de Møgluglu ?
Non, il parle de ton code VB. Le DoEvents de VB
retourne immédiatement s'il n'y a rien à faire, et
tu vas donc consommer beaucoup de CPU dans ta boucle.
La fonction GetMessage de Win32 est différente, elle
est bloquante tant qu'il n'y a pas de message et tu
ne vas donc pas consommer de CPU quand tu seras dedans.
> ça me dérange ta boucle while(!bOk). > c'est de l'attente active. > c'est pourri et inutile.
donc tu préconises la méthode de Møgluglu ?
Non, il parle de ton code VB. Le DoEvents de VB retourne immédiatement s'il n'y a rien à faire, et tu vas donc consommer beaucoup de CPU dans ta boucle. La fonction GetMessage de Win32 est différente, elle est bloquante tant qu'il n'y a pas de message et tu ne vas donc pas consommer de CPU quand tu seras dedans.
PurL
Manuel Leclerc wrote:
PurL a écrit :
Mon programme doit exploiter les fichiers d'un autre programme tous les jours à minuit (déclencher par le gestionnaire des taches). Or il arrive que certains fichiers sont inaccessibles pour des raisons que j'ignore encore.
Je pense que la première chose à faire est de récupérer la code retour de l'erreur d'ouverture des fichiers :-) C'est quelle valeur ?
C'est dans un try catch, quand j'essai de l'ouvrir une exception se déclenche avec le message : "Impossible d'ouvrir le fichier" Quand on essai ultérieurement, ca marche, et puis ca va le faire 1 fois sur 10 et en plus pas sur le meme fichier :( le truc bien aléatoire en somme :)
PurL
Manuel Leclerc wrote:
PurL a écrit :
Mon programme doit exploiter les fichiers d'un autre
programme tous les jours à minuit (déclencher par le
gestionnaire des taches). Or il arrive que certains
fichiers sont inaccessibles pour des raisons que
j'ignore encore.
Je pense que la première chose à faire est de
récupérer la code retour de l'erreur d'ouverture des
fichiers :-) C'est quelle valeur ?
C'est dans un try catch, quand j'essai de l'ouvrir une exception se
déclenche avec le message : "Impossible d'ouvrir le fichier"
Quand on essai ultérieurement, ca marche, et puis ca va le faire 1 fois sur
10 et en plus pas sur le meme fichier :( le truc bien aléatoire en somme :)
Mon programme doit exploiter les fichiers d'un autre programme tous les jours à minuit (déclencher par le gestionnaire des taches). Or il arrive que certains fichiers sont inaccessibles pour des raisons que j'ignore encore.
Je pense que la première chose à faire est de récupérer la code retour de l'erreur d'ouverture des fichiers :-) C'est quelle valeur ?
C'est dans un try catch, quand j'essai de l'ouvrir une exception se déclenche avec le message : "Impossible d'ouvrir le fichier" Quand on essai ultérieurement, ca marche, et puis ca va le faire 1 fois sur 10 et en plus pas sur le meme fichier :( le truc bien aléatoire en somme :)
PurL
Manuel Leclerc
PurL a écrit :
C'est dans un try catch, quand j'essai de l'ouvrir une exception se déclenche avec le message : "Impossible d'ouvrir le fichier" Quand on essai ultérieurement, ca marche, et puis ca va le faire 1 fois sur 10 et en plus pas sur le meme fichier :( le truc bien aléatoire en somme :)
Les trucs "aléatoires" qui provoquent une erreur d'ouverture de fichier, je n'y _crois_ pas :-)
fais du C a cet endroit là, avec la bonne vieille méthode :
Tu pourras, par exemple, être surpris par la valeur de "argument" qui sera tracée :-)
PurL a écrit :
C'est dans un try catch, quand j'essai de l'ouvrir
une exception se déclenche avec le message :
"Impossible d'ouvrir le fichier" Quand on essai
ultérieurement, ca marche, et puis ca va le faire
1 fois sur 10 et en plus pas sur le meme
fichier :( le truc bien aléatoire en somme :)
Les trucs "aléatoires" qui provoquent une erreur
d'ouverture de fichier, je n'y _crois_ pas :-)
fais du C a cet endroit là, avec la bonne vieille
méthode :
C'est dans un try catch, quand j'essai de l'ouvrir une exception se déclenche avec le message : "Impossible d'ouvrir le fichier" Quand on essai ultérieurement, ca marche, et puis ca va le faire 1 fois sur 10 et en plus pas sur le meme fichier :( le truc bien aléatoire en somme :)
Les trucs "aléatoires" qui provoquent une erreur d'ouverture de fichier, je n'y _crois_ pas :-)
fais du C a cet endroit là, avec la bonne vieille méthode :
Tu pourras, par exemple, être surpris par la valeur de "argument" qui sera tracée :-)
Møgluglu
Manuel Leclerc a écrit:
PurL a écrit :
donc tu préconises la méthode de Møgluglu ?
Non, il parle de ton code VB.
Euh, si, je parlais bien du code C, en proposant simplement de remplacer l'affreux polling sur un booléen par un event.
La fonction GetMessage de Win32 est différente, elle est bloquante tant qu'il n'y a pas de message et tu ne vas donc pas consommer de CPU quand tu seras dedans.
Voui mais c'est un programme console, donc sans boucle de messages...
-- Møgluglu
Manuel Leclerc a écrit:
PurL a écrit :
donc tu préconises la méthode de Møgluglu ?
Non, il parle de ton code VB.
Euh, si, je parlais bien du code C, en proposant simplement de
remplacer l'affreux polling sur un booléen par un event.
La fonction GetMessage de Win32 est différente, elle
est bloquante tant qu'il n'y a pas de message et tu
ne vas donc pas consommer de CPU quand tu seras dedans.
Voui mais c'est un programme console, donc sans boucle de messages...
Euh, si, je parlais bien du code C, en proposant simplement de remplacer l'affreux polling sur un booléen par un event.
La fonction GetMessage de Win32 est différente, elle est bloquante tant qu'il n'y a pas de message et tu ne vas donc pas consommer de CPU quand tu seras dedans.
Voui mais c'est un programme console, donc sans boucle de messages...
-- Møgluglu
Manuel Leclerc
Møgluglu a écrit :
Manuel Leclerc a écrit:
> PurL a écrit :
> > donc tu préconises la méthode de Møgluglu ? > > Non, il parle de ton code VB.
Euh, si, je parlais bien du code C, en proposant simplement de remplacer l'affreux polling sur un booléen par un event.
Quand j'ai écrit "il parle de ton code VB" je parlais de "Ambassadeur Kosh", pas de toi.
Ceci dit, je viens de relire le post de l'ambassadeur, et je ne sais plus trop de quoi il parlait en fait :-)
A part ça, ton histoire d'Event, je n'y ai rien compris. Si tu crée un Event et que tu attends dessus avec WaitForSingleObject, j'aimerais bien que tu me dises qui va appeler la fontion SetEvent ... hum
> La fonction GetMessage de Win32 est différente, elle > est bloquante tant qu'il n'y a pas de message et tu > ne vas donc pas consommer de CPU quand tu seras dedans.
Voui mais c'est un programme console, donc sans boucle de messages...
Non. Un programme console a une message queue, peut créer des fenêtres, et tout le tremblement.
Møgluglu a écrit :
Manuel Leclerc a écrit:
> PurL a écrit :
> > donc tu préconises la méthode de Møgluglu ?
>
> Non, il parle de ton code VB.
Euh, si, je parlais bien du code C, en proposant
simplement de remplacer l'affreux polling sur un
booléen par un event.
Quand j'ai écrit "il parle de ton code VB" je parlais
de "Ambassadeur Kosh", pas de toi.
Ceci dit, je viens de relire le post de l'ambassadeur,
et je ne sais plus trop de quoi il parlait en fait :-)
A part ça, ton histoire d'Event, je n'y ai rien compris.
Si tu crée un Event et que tu attends dessus avec
WaitForSingleObject, j'aimerais bien que tu me dises
qui va appeler la fontion SetEvent ... hum
> La fonction GetMessage de Win32 est différente, elle
> est bloquante tant qu'il n'y a pas de message et tu
> ne vas donc pas consommer de CPU quand tu seras dedans.
Voui mais c'est un programme console, donc sans boucle
de messages...
Non. Un programme console a une message queue, peut créer
des fenêtres, et tout le tremblement.
> > donc tu préconises la méthode de Møgluglu ? > > Non, il parle de ton code VB.
Euh, si, je parlais bien du code C, en proposant simplement de remplacer l'affreux polling sur un booléen par un event.
Quand j'ai écrit "il parle de ton code VB" je parlais de "Ambassadeur Kosh", pas de toi.
Ceci dit, je viens de relire le post de l'ambassadeur, et je ne sais plus trop de quoi il parlait en fait :-)
A part ça, ton histoire d'Event, je n'y ai rien compris. Si tu crée un Event et que tu attends dessus avec WaitForSingleObject, j'aimerais bien que tu me dises qui va appeler la fontion SetEvent ... hum
> La fonction GetMessage de Win32 est différente, elle > est bloquante tant qu'il n'y a pas de message et tu > ne vas donc pas consommer de CPU quand tu seras dedans.
Voui mais c'est un programme console, donc sans boucle de messages...
Non. Un programme console a une message queue, peut créer des fenêtres, et tout le tremblement.
ça me dérange ta boucle while(!bOk). c'est de l'attente active. c'est pourri et inutile.
Et le Sleep alors? Ce n 'est pas de l'attente active! Arnaud
Manuel Leclerc
Christian ASTOR a écrit :
Manuel Leclerc a écrit:
> Non. Un programme console a une message queue
Non. KB 102482
Cet article dit qu'on ne "devrait" pas utiliser SetTimer dans une application console. et qu'on peut s'en passer en faisant autrement. Soit. Je suppose que Microsoft veut prévenir les développeurs que peut être, un jour, ça ne marchera plus. Donc acte. Je signale quand même que j'ai retrouvé la technique du SetTimer dans une application console dans le "Under The Hood" de Matt Pietrek (Microsoft System Journal, mars 1997).
A part ça, SI "un programme console a une message queue", comme je le disais. Extrait de MSDN : "Any thread can create a window". En particulier n'importe quel thread d'une application console, et en particulier le thread 1. Si un jour, il n'est plus possible de créer des fenêtres à partir d'un thread d'une application console, un _gros_ paquet d'application ne vont plus marcher.
Christian ASTOR a écrit :
Manuel Leclerc a écrit:
> Non. Un programme console a une message queue
Non.
KB 102482
Cet article dit qu'on ne "devrait" pas utiliser SetTimer
dans une application console. et qu'on peut s'en passer
en faisant autrement. Soit. Je suppose que Microsoft
veut prévenir les développeurs que peut être, un jour,
ça ne marchera plus. Donc acte. Je signale quand même
que j'ai retrouvé la technique du SetTimer dans une
application console dans le "Under The Hood" de Matt Pietrek
(Microsoft System Journal, mars 1997).
A part ça, SI "un programme console a une message queue",
comme je le disais. Extrait de MSDN : "Any thread can
create a window". En particulier n'importe quel thread
d'une application console, et en particulier le thread 1.
Si un jour, il n'est plus possible de créer des fenêtres
à partir d'un thread d'une application console, un _gros_
paquet d'application ne vont plus marcher.
Cet article dit qu'on ne "devrait" pas utiliser SetTimer dans une application console. et qu'on peut s'en passer en faisant autrement. Soit. Je suppose que Microsoft veut prévenir les développeurs que peut être, un jour, ça ne marchera plus. Donc acte. Je signale quand même que j'ai retrouvé la technique du SetTimer dans une application console dans le "Under The Hood" de Matt Pietrek (Microsoft System Journal, mars 1997).
A part ça, SI "un programme console a une message queue", comme je le disais. Extrait de MSDN : "Any thread can create a window". En particulier n'importe quel thread d'une application console, et en particulier le thread 1. Si un jour, il n'est plus possible de créer des fenêtres à partir d'un thread d'une application console, un _gros_ paquet d'application ne vont plus marcher.
Christian ASTOR
Manuel Leclerc a écrit:
A part ça, SI "un programme console a une message queue",
" SetTimer() was not designed to be used with a console application because it requires a message loop " Une appli console n'a pas de *message* loop (I/O events) Il suffit d'en rajouter 1 avec GetMessage() et on voit que msg.message est tjrs = 0.
Mais bien sûr qu'on peut créer ensuite des fenêtres.
Manuel Leclerc a écrit:
A part ça, SI "un programme console a une message queue",
"
SetTimer() was not designed to be used with a console application
because it requires a message loop
"
Une appli console n'a pas de *message* loop (I/O events)
Il suffit d'en rajouter 1 avec GetMessage() et on voit que msg.message
est tjrs = 0.
Mais bien sûr qu'on peut créer ensuite des fenêtres.
A part ça, SI "un programme console a une message queue",
" SetTimer() was not designed to be used with a console application because it requires a message loop " Une appli console n'a pas de *message* loop (I/O events) Il suffit d'en rajouter 1 avec GetMessage() et on voit que msg.message est tjrs = 0.
Mais bien sûr qu'on peut créer ensuite des fenêtres.
Ambassadeur Kosh
> Ceci dit, je viens de relire le post de l'ambassadeur, et je ne sais plus trop de quoi il parlait en fait :-)
et pour cause, le polling est une daube independament du langage.
> Voui mais c'est un programme console, donc sans boucle > de messages... Non. Un programme console a une message queue, peut créer des fenêtres, et tout le tremblement.
la je ne sais pas. à en croire christian, non. et la dessus, on peut le croire.
par contre, si tu fais un "programme fenêtre", et que tu cree et assignes une console dynamiquement en redirigeant cin, cout et cerr dessus, ça, ça marche trés bien. tu as le beurre et l'argent du beurre. je vais rechercher le bout de code qui fait ça.
ou peut être que la console n'est pas une fin en soi, faut voir...
> Ceci dit, je viens de relire le post de l'ambassadeur,
et je ne sais plus trop de quoi il parlait en fait :-)
et pour cause, le polling est une daube independament du langage.
> Voui mais c'est un programme console, donc sans boucle
> de messages...
Non. Un programme console a une message queue, peut créer
des fenêtres, et tout le tremblement.
la je ne sais pas.
à en croire christian, non. et la dessus, on peut le croire.
par contre, si tu fais un "programme fenêtre", et que tu cree et assignes
une console dynamiquement en redirigeant cin, cout et cerr dessus, ça, ça
marche trés bien.
tu as le beurre et l'argent du beurre. je vais rechercher le bout de code
qui fait ça.
ou peut être que la console n'est pas une fin en soi, faut voir...
> Ceci dit, je viens de relire le post de l'ambassadeur, et je ne sais plus trop de quoi il parlait en fait :-)
et pour cause, le polling est une daube independament du langage.
> Voui mais c'est un programme console, donc sans boucle > de messages... Non. Un programme console a une message queue, peut créer des fenêtres, et tout le tremblement.
la je ne sais pas. à en croire christian, non. et la dessus, on peut le croire.
par contre, si tu fais un "programme fenêtre", et que tu cree et assignes une console dynamiquement en redirigeant cin, cout et cerr dessus, ça, ça marche trés bien. tu as le beurre et l'argent du beurre. je vais rechercher le bout de code qui fait ça.
ou peut être que la console n'est pas une fin en soi, faut voir...
