J'aurais besoin d'un contr=F4le si possible (ou un API) me permettant =
d'ajouter une minuterie =E0 mon application, c'est-=E0-dire un Label qui =
affiche par exemple "2 minutes" et qui baisse d'une seconde =E0 chaque =
seconde bien entendu.
Je sais que cela est possible avec un Timer normal, mais si =
l'utilisateur a un moins gros PC le Timer "lag" et je voudrais =
rem=E9dier =E0 =E7a.
Merci d'avance =E0 tout ceux qui proposeront leur aide.
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
François Picalausa
Bonjour/soir,
Les APIs SetTimer et KillTimer sont un rien plus précises que le contrôle timer.
Tu pourrais aussi utiliser le timer des procédures de synchronisations (http://msdn.microsoft.com/library/en-us/dllproc/base/using_waitable_timer_o bjects.asp) mais non disponibles avant Win95 et je ne sais pas quelle est leur précision.
Les Multimedia Timers permettent une grande précision mais dans le cas d'applications (multimédia) qui ont besoin d'un interval de temps très faible, elles ne sont pas conseillées.
Les objets scripting proposent aussi des timers.. mais pourquoi employer des objets scripting quand on a tout ce qu'il faut en VB?
MSHTML propose son propre modèle de timer haute précision (http://msdn.microsoft.com/workshop/browser/timer/timer.asp) mais cela signifie aussi dépendre de Internet Explorer!
WMI fournit aussi de quoi utiliser un timer : http://msdn.microsoft.com/library/en-us/wmisdk/wmi/creating_a_timer_event_with___timerinstruction.asp
Si quelqu'un voit d'autres timers, ne pas hésiter ;-)
Dans ce cas ci, si le contrôle timer n'est pas assez précise, je pense que l'emploi de SetTimer/KillTimer dans un module, indépendant d'une fenêtre, serait plus approprié: http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/timers/timerreference/timerfunctions/settimer.asp
J'aurais besoin d'un contrôle si possible (ou un API) me permettant d'ajouter une minuterie à mon application, c'est-à-dire un Label qui affiche par exemple "2 minutes" et qui baisse d'une seconde à chaque seconde bien entendu.
Je sais que cela est possible avec un Timer normal, mais si l'utilisateur a un moins gros PC le Timer "lag" et je voudrais remédier à ça.
Merci d'avance à tout ceux qui proposeront leur aide.
Cordialement Daniel - Z
Bonjour/soir,
Les APIs SetTimer et KillTimer sont un rien plus précises que le contrôle
timer.
Tu pourrais aussi utiliser le timer des procédures de synchronisations
(http://msdn.microsoft.com/library/en-us/dllproc/base/using_waitable_timer_o
bjects.asp) mais non disponibles avant Win95 et je ne sais pas quelle est
leur précision.
Les Multimedia Timers permettent une grande précision mais dans le cas
d'applications (multimédia) qui ont besoin d'un interval de temps très
faible, elles ne sont pas conseillées.
Les objets scripting proposent aussi des timers.. mais pourquoi employer des
objets scripting quand on a tout ce qu'il faut en VB?
MSHTML propose son propre modèle de timer haute précision
(http://msdn.microsoft.com/workshop/browser/timer/timer.asp) mais cela
signifie aussi dépendre de Internet Explorer!
WMI fournit aussi de quoi utiliser un timer :
http://msdn.microsoft.com/library/en-us/wmisdk/wmi/creating_a_timer_event_with___timerinstruction.asp
Si quelqu'un voit d'autres timers, ne pas hésiter ;-)
Dans ce cas ci, si le contrôle timer n'est pas assez précise, je pense que
l'emploi de SetTimer/KillTimer dans un module, indépendant d'une fenêtre,
serait plus approprié:
http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/timers/timerreference/timerfunctions/settimer.asp
"Daniel - Z" <NOSPAM_daniel.z@laposte.net> a écrit dans le message de
news:%23iF7V0nnDHA.1072@TK2MSFTNGP09.phx.gbl
Bonjour.
J'aurais besoin d'un contrôle si possible (ou un API) me permettant
d'ajouter une minuterie à mon application, c'est-à-dire un Label qui
affiche par exemple "2 minutes" et qui baisse d'une seconde à chaque
seconde bien entendu.
Je sais que cela est possible avec un Timer normal, mais si
l'utilisateur a un moins gros PC le Timer "lag" et je voudrais
remédier à ça.
Merci d'avance à tout ceux qui proposeront leur aide.
Les APIs SetTimer et KillTimer sont un rien plus précises que le contrôle timer.
Tu pourrais aussi utiliser le timer des procédures de synchronisations (http://msdn.microsoft.com/library/en-us/dllproc/base/using_waitable_timer_o bjects.asp) mais non disponibles avant Win95 et je ne sais pas quelle est leur précision.
Les Multimedia Timers permettent une grande précision mais dans le cas d'applications (multimédia) qui ont besoin d'un interval de temps très faible, elles ne sont pas conseillées.
Les objets scripting proposent aussi des timers.. mais pourquoi employer des objets scripting quand on a tout ce qu'il faut en VB?
MSHTML propose son propre modèle de timer haute précision (http://msdn.microsoft.com/workshop/browser/timer/timer.asp) mais cela signifie aussi dépendre de Internet Explorer!
WMI fournit aussi de quoi utiliser un timer : http://msdn.microsoft.com/library/en-us/wmisdk/wmi/creating_a_timer_event_with___timerinstruction.asp
Si quelqu'un voit d'autres timers, ne pas hésiter ;-)
Dans ce cas ci, si le contrôle timer n'est pas assez précise, je pense que l'emploi de SetTimer/KillTimer dans un module, indépendant d'une fenêtre, serait plus approprié: http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/timers/timerreference/timerfunctions/settimer.asp
J'aurais besoin d'un contrôle si possible (ou un API) me permettant d'ajouter une minuterie à mon application, c'est-à-dire un Label qui affiche par exemple "2 minutes" et qui baisse d'une seconde à chaque seconde bien entendu.
Je sais que cela est possible avec un Timer normal, mais si l'utilisateur a un moins gros PC le Timer "lag" et je voudrais remédier à ça.
Merci d'avance à tout ceux qui proposeront leur aide.
Cordialement Daniel - Z
Zoury
Salut!
Dans ce cas ci, si le contrôle timer n'est pas assez précise, je pense que l'emploi de SetTimer/KillTimer dans un module, indépendant d'une fenêtre, serait plus approprié:
Pour préciser un peu, le contrôle Timer n'as en fait pas une grande priorité dans la liste des tâches ce qui cause son imprécision... si le système est occupé à une tâche plus importante ce sont les tâches moins importantes qui en écoppe.
Si quelqu'un voit d'autres timers, ne pas hésiter ;-)
en voici un autre..
High-Performance Timer Objects - Karl E. Peterson http://www.mvps.org/ccrp/controls/ccrptimer6.htm
Merci de poster les réponses au groupe afin d'en faire profiter à tous
Salut!
Dans ce cas ci, si le contrôle timer n'est pas assez précise, je pense que
l'emploi de SetTimer/KillTimer dans un module, indépendant d'une fenêtre,
serait plus approprié:
Pour préciser un peu, le contrôle Timer n'as en fait pas une grande priorité
dans la liste des tâches ce qui cause son imprécision... si le système est
occupé à une tâche plus importante ce sont les tâches moins importantes qui
en écoppe.
Si quelqu'un voit d'autres timers, ne pas hésiter ;-)
en voici un autre..
High-Performance Timer Objects - Karl E. Peterson
http://www.mvps.org/ccrp/controls/ccrptimer6.htm
Dans ce cas ci, si le contrôle timer n'est pas assez précise, je pense que l'emploi de SetTimer/KillTimer dans un module, indépendant d'une fenêtre, serait plus approprié:
Pour préciser un peu, le contrôle Timer n'as en fait pas une grande priorité dans la liste des tâches ce qui cause son imprécision... si le système est occupé à une tâche plus importante ce sont les tâches moins importantes qui en écoppe.
Si quelqu'un voit d'autres timers, ne pas hésiter ;-)
en voici un autre..
High-Performance Timer Objects - Karl E. Peterson http://www.mvps.org/ccrp/controls/ccrptimer6.htm
Merci à vous deux pour les réponses précises. J'ai maintenant tous les outils à ma disposition.
Merci encore.
Cordialement Daniel - Z
Fabrice MALAINGRE
Bonjour à tous,
> Les APIs SetTimer et KillTimer sont un rien plus précises > que le contrôle timer.
Ah bon ! Très honnêtement, il s'agit rigoureusement du même mécanisme sous-jacent. C'est-à-dire l'envoi de messages WM_TIMER.
Pour préciser un peu, le contrôle Timer n'as en fait pas une grande priorité dans la liste des tâches ce qui cause son imprécision... si le système est occupé à une tâche plus importante ce sont les tâches moins importantes qui en écoppe.
Le fait que ce type de timer soit totalement imprécis réside moins dans le niveau de priorité des threads dans lesquels il s'exécute, que dans son architecture. Il s'agit en fait de simple message WM_TIMER qui sont postés à intervalle régulier. Quand l'on sait le nombre de messages traités par les « WindowProc » de nos fenêtre applicatives, il ne faut pas s'étonner du peu de précision de ce mécanisme. Il suffit que l'utilisateur se mette à cliquer partout, ou à bouger sa fenêtre dans tous les sens, pour saturer la file de messages, et donc pour rendre les WM_TIMER totalement aléatoires !
Les Multimedia Timers permettent une grande précision mais dans le cas d'applications (multimédia) qui ont besoin d'un interval de temps très faible, elles ne sont pas conseillées.
Pourquoi « pas conseillées » ! En effet, il s'agit là des timers les plus précis disponibles dans le système. Ils sont même un peu « magique », dans la mesure où ils sont capables de faire descendre l'intégralité du système à des fréquences non habituelles. Je m'explique, Windows NT/W2K/XP tourne de manière native à 10ms. Si un processus du système utilise l'instruction « BeginPeriod », l'intégralité du noyau se met à fournir des services à la résolution demandée, celle-ci allant jusqu'à 1 ms (tout ceci étant évidemment dépendant du matériel).
Si quelqu'un voit d'autres timers, ne pas hésiter ;-)
Il reste les « Waitable Times ». Deux avantages à leur utilisation : 1) Il s'agit d'objets noyaux, donc manipulables via un HANDLE, et donc pouvant donc être partagés entre plusieurs processus. 2) La routine appelée à l'échéance du timer peut s'exécutée en tant qu'APC (et donc à niveau de priorité supérieur à n'importe quel thread du système) pourvu que le thread en attente sur le timer soit en état « Alertable » (utilisation de « WaitForSingleObjectEx »).
Et pour les cas extrêmes, (i.e. implémentation de son propre mécanisme de timer) la mesure du temps à l'aide de « QueryPerformanceTimer » s'impose.
Cordialement
____________________________ Fabrice MALAINGRE Architecte Logiciel - Chef de Projet THEORIS - www.theoris.fr
Bonjour à tous,
> Les APIs SetTimer et KillTimer sont un rien plus précises
> que le contrôle timer.
Ah bon ! Très honnêtement, il s'agit rigoureusement du même mécanisme
sous-jacent. C'est-à-dire l'envoi de messages WM_TIMER.
Pour préciser un peu, le contrôle Timer n'as en fait pas
une grande priorité dans la liste des tâches ce
qui cause son imprécision... si le système est
occupé à une tâche plus importante ce sont
les tâches moins importantes qui en écoppe.
Le fait que ce type de timer soit totalement imprécis réside moins dans le
niveau de priorité des threads dans lesquels il s'exécute, que dans son
architecture.
Il s'agit en fait de simple message WM_TIMER qui sont postés à intervalle
régulier.
Quand l'on sait le nombre de messages traités par les « WindowProc » de nos
fenêtre applicatives, il ne faut pas s'étonner du peu de précision de ce
mécanisme.
Il suffit que l'utilisateur se mette à cliquer partout, ou à bouger sa
fenêtre dans tous les sens, pour saturer la file de messages, et donc pour
rendre les WM_TIMER totalement aléatoires !
Les Multimedia Timers permettent une grande
précision mais dans le cas d'applications (multimédia)
qui ont besoin d'un interval de temps très
faible, elles ne sont pas conseillées.
Pourquoi « pas conseillées » ! En effet, il s'agit là des timers les plus
précis disponibles dans le système.
Ils sont même un peu « magique », dans la mesure où ils sont capables de
faire descendre l'intégralité du système à des fréquences non habituelles.
Je m'explique, Windows NT/W2K/XP tourne de manière native à 10ms. Si un
processus du système utilise l'instruction « BeginPeriod », l'intégralité du
noyau se met à fournir des services à la résolution demandée, celle-ci
allant jusqu'à 1 ms (tout ceci étant évidemment dépendant du matériel).
Si quelqu'un voit d'autres timers, ne pas hésiter ;-)
Il reste les « Waitable Times ». Deux avantages à leur utilisation :
1) Il s'agit d'objets noyaux, donc manipulables via un HANDLE, et donc
pouvant donc être partagés entre plusieurs processus.
2) La routine appelée à l'échéance du timer peut s'exécutée en tant qu'APC
(et donc à niveau de priorité supérieur à n'importe quel thread du système)
pourvu que le thread en attente sur le timer soit en état « Alertable »
(utilisation de « WaitForSingleObjectEx »).
Et pour les cas extrêmes, (i.e. implémentation de son propre mécanisme de
timer) la mesure du temps à l'aide de « QueryPerformanceTimer » s'impose.
Cordialement
____________________________
Fabrice MALAINGRE
Architecte Logiciel - Chef de Projet
THEORIS - www.theoris.fr
> Les APIs SetTimer et KillTimer sont un rien plus précises > que le contrôle timer.
Ah bon ! Très honnêtement, il s'agit rigoureusement du même mécanisme sous-jacent. C'est-à-dire l'envoi de messages WM_TIMER.
Pour préciser un peu, le contrôle Timer n'as en fait pas une grande priorité dans la liste des tâches ce qui cause son imprécision... si le système est occupé à une tâche plus importante ce sont les tâches moins importantes qui en écoppe.
Le fait que ce type de timer soit totalement imprécis réside moins dans le niveau de priorité des threads dans lesquels il s'exécute, que dans son architecture. Il s'agit en fait de simple message WM_TIMER qui sont postés à intervalle régulier. Quand l'on sait le nombre de messages traités par les « WindowProc » de nos fenêtre applicatives, il ne faut pas s'étonner du peu de précision de ce mécanisme. Il suffit que l'utilisateur se mette à cliquer partout, ou à bouger sa fenêtre dans tous les sens, pour saturer la file de messages, et donc pour rendre les WM_TIMER totalement aléatoires !
Les Multimedia Timers permettent une grande précision mais dans le cas d'applications (multimédia) qui ont besoin d'un interval de temps très faible, elles ne sont pas conseillées.
Pourquoi « pas conseillées » ! En effet, il s'agit là des timers les plus précis disponibles dans le système. Ils sont même un peu « magique », dans la mesure où ils sont capables de faire descendre l'intégralité du système à des fréquences non habituelles. Je m'explique, Windows NT/W2K/XP tourne de manière native à 10ms. Si un processus du système utilise l'instruction « BeginPeriod », l'intégralité du noyau se met à fournir des services à la résolution demandée, celle-ci allant jusqu'à 1 ms (tout ceci étant évidemment dépendant du matériel).
Si quelqu'un voit d'autres timers, ne pas hésiter ;-)
Il reste les « Waitable Times ». Deux avantages à leur utilisation : 1) Il s'agit d'objets noyaux, donc manipulables via un HANDLE, et donc pouvant donc être partagés entre plusieurs processus. 2) La routine appelée à l'échéance du timer peut s'exécutée en tant qu'APC (et donc à niveau de priorité supérieur à n'importe quel thread du système) pourvu que le thread en attente sur le timer soit en état « Alertable » (utilisation de « WaitForSingleObjectEx »).
Et pour les cas extrêmes, (i.e. implémentation de son propre mécanisme de timer) la mesure du temps à l'aide de « QueryPerformanceTimer » s'impose.
Cordialement
____________________________ Fabrice MALAINGRE Architecte Logiciel - Chef de Projet THEORIS - www.theoris.fr
Zoury
Bonjour Fabrice! :O)
Un gros merci à notre architecte logiciel préféré qui a, une fois de plus, éclairé nos lanterne avec brio! ;O)
Merci de poster les réponses au groupe afin d'en faire profiter à tous
François Picalausa
Bonjour/soir,
"Fabrice MALAINGRE" a écrit dans le message de news:%
Bonjour à tous,
Les APIs SetTimer et KillTimer sont un rien plus précises que le contrôle timer.
Ah bon ! Très honnêtement, il s'agit rigoureusement du même mécanisme sous-jacent. C'est-à-dire l'envoi de messages WM_TIMER.
Le contrôle fait faire des appels aux APIs par VB.. on a un intermédiaire ;-) Mais il me semble surtout qu'on a pas le problème de la priorité du message quand on ne passe pas de fenêtre...
Les Multimedia Timers permettent une grande précision mais dans le cas d'applications (multimédia) qui ont besoin d'un interval de temps très faible, elles ne sont pas conseillées.
Pourquoi « pas conseillées » !
peut-être à cause d'une double négation dans la phrase de base, que j'en ai viré une et oublié l'autre? ooooppppppssss....
Si quelqu'un voit d'autres timers, ne pas hésiter ;-)
Il reste les « Waitable Times ».
Je disais justement "Tu pourrais aussi utiliser le timer des procédures de synchronisations".. merci pour la précision sur le nom :-)
Merci pour ces précisions :-) -- François Picalausa (MVP VB) FAQ VB : http://faq.vb.free.fr MSDN : http://msdn.microsoft.com
Bonjour/soir,
"Fabrice MALAINGRE" <nospam@theoris.fr> a écrit dans le message de
news:%23QtzZv7nDHA.2772@TK2MSFTNGP12.phx.gbl
Bonjour à tous,
Les APIs SetTimer et KillTimer sont un rien plus précises
que le contrôle timer.
Ah bon ! Très honnêtement, il s'agit rigoureusement du même mécanisme
sous-jacent. C'est-à-dire l'envoi de messages WM_TIMER.
Le contrôle fait faire des appels aux APIs par VB.. on a un intermédiaire
;-)
Mais il me semble surtout qu'on a pas le problème de la priorité du message
quand on ne passe pas de fenêtre...
Les Multimedia Timers permettent une grande
précision mais dans le cas d'applications (multimédia)
qui ont besoin d'un interval de temps très
faible, elles ne sont pas conseillées.
Pourquoi « pas conseillées » !
peut-être à cause d'une double négation dans la phrase de base, que j'en ai
viré une et oublié l'autre? ooooppppppssss....
Si quelqu'un voit d'autres timers, ne pas hésiter ;-)
Il reste les « Waitable Times ».
Je disais justement "Tu pourrais aussi utiliser le timer des procédures de
synchronisations".. merci pour la précision sur le nom :-)
Merci pour ces précisions :-)
--
François Picalausa (MVP VB)
FAQ VB : http://faq.vb.free.fr
MSDN : http://msdn.microsoft.com
"Fabrice MALAINGRE" a écrit dans le message de news:%
Bonjour à tous,
Les APIs SetTimer et KillTimer sont un rien plus précises que le contrôle timer.
Ah bon ! Très honnêtement, il s'agit rigoureusement du même mécanisme sous-jacent. C'est-à-dire l'envoi de messages WM_TIMER.
Le contrôle fait faire des appels aux APIs par VB.. on a un intermédiaire ;-) Mais il me semble surtout qu'on a pas le problème de la priorité du message quand on ne passe pas de fenêtre...
Les Multimedia Timers permettent une grande précision mais dans le cas d'applications (multimédia) qui ont besoin d'un interval de temps très faible, elles ne sont pas conseillées.
Pourquoi « pas conseillées » !
peut-être à cause d'une double négation dans la phrase de base, que j'en ai viré une et oublié l'autre? ooooppppppssss....
Si quelqu'un voit d'autres timers, ne pas hésiter ;-)
Il reste les « Waitable Times ».
Je disais justement "Tu pourrais aussi utiliser le timer des procédures de synchronisations".. merci pour la précision sur le nom :-)
Merci pour ces précisions :-) -- François Picalausa (MVP VB) FAQ VB : http://faq.vb.free.fr MSDN : http://msdn.microsoft.com
