comme vous aller l'air à bien connaître les timer, j'ai une question pour vous. J'ai fais un petit programme console qui va vérifier l'utilisation du CPU et de la mémoire sur un Serveur (Windows server 2003). Ensuite, celui-ci enregistre les données dans la BD et enregistre également une erreur dans la BD si le % d'utilisation préalablement déterminé est dépassé. J'utilise un timer (VB) pour vérifier l'utilisation CPU/MEM, l'intervalle est prédéfini par un utilisateur. Tout fonctionne bien. Cependant, après un certain temps aléatoire, le timer arrête sans raison apparente. Aucune erreur enregistré dans Event LOG, aucune exeption "catcher" dans le programme non plus. Auriez-vous une idée de la cause de ce problème et qu'est-ce que je pourrais faire pour remédier à cette situation ?
code -> parce que je suis dans les OCX depuis peu, c'est pour me faire la main.
parce qu'en classe, çà existe déjà.
pour vraiment remplacer le TimerVB, donc dans les outils ;)
(mais tu es le 2e à m'en faire la remarque)
distribution -> l'ocx compilé est fourni dans un fichier Release, je ne vois pas le problème de référencer un projet recompilable, à un projet exemple....
ou alors j'ai mal compris.... (?)
Afyn -> ok, merci pour ces précisions. je ne pense pas faire évoluer ce timer, pour le moment du moins, mais j'ai feuilleté un peu la MSDN en rapport à tes informations.
peut-être m'y plongerais-je + un jour...
All -> zip mis à jour, avec la correction de l'intervalle (le "End If" trop haut).
et j'en ai profité pour le passer à 10 par défaut et 10 en cas d'erreur, en laissant la possibilité de le descendre jusqu'à 1 comme le Timer VB (même si il n'y en a pas d'utilité)
Quelques Infos :
Plusieurs Types de Timers :
Timer VB : intervalle min 18 ms !
Timer API SetTimer : intervalle min 10 ms (low priority)
Pour avoir un intervalle à la milliseconde :
Multimedia Timer : (winMM.dll) Win 95 -> Win XP
- Il faut que le PC soit équipé d'un Timer assez précis
(mais ça semble etre le cas de tous les PC !)
- Il faut régler la précision de l'horloge interne au max
- Le timer crée un Thread supplémentaire
-> un trés bon exemple Le RSTimer (environ 1 % du proc)
composant free mais sans les sources
Ensuite viens le waitable timer soit disant plus léger
en ressource, qui s'éxécute dans le même thread, peut
être utile pour débugger. précis 1 ms également en ajustant
l'horloge système avec les API WinMM.
Sur XP, le top serait le TimerQueueTimer, moins de ressources
processeur. Mais là ... entre la théorie et la pratique ...
Si tu veux je te passe un exemple ... de code qui marche
dans l'IDE, mais qui plante en compilé quand on essaye
d'accéder à des variables Objets (commme un shape par ex)
Impossible de trouver un exemple fonctionnel. J'aimerai
bien que quelqu'un m'explique pourquoi ça plante ?
(peut etre un appel a la vm qui n'est pas safe)
Voilà, mes connaissance ne vont guère plus loin ...
En fait, il faudrait également connaitre le système
de message win, savoir quels messages sont traités
avant les autres pour mettre aux point un timer,
car ça ne sert à rien de savoir envoyer des
messages de façon précises, s'il sont traités
en dernier ...
Il y a surement des trucs à explorer du coté des
interruptions, ou de la façon dont sont programmé
les drivers.
Afyn -> la seule source qui parle apparemment de cette API, c'est là tienne ;)
mis à par MSDN où je viens de trouver des infos.
seulement, en comparaison avec ta source, pour les performances, en passant par SetTimer, mon PC est entre 18% et 24% d'utilisation (avec le reste qui tourne) à intervalle de 10ms. avec ta TimerQueue..., entre 48% et 73%. et 100% en 1ms.
tu peux me donner plus d'infos? dans le sens...., m'expliquer pourquoi je devrais modifier mon timer pour qu'il décolle les dissipateurs thermiques :-p
les 10ms, donc l'équart minimal réel pour le CallBack, ok, mais ce n'est qu'un timer. celui de VB est à 18ms. çà me paraît pas mal déjà. après, pour avoir des performances plus précises entre 2 évènements, il suffit de basculer en mode BenchMark. vous pouvez par exemple mesurer :
Dim I as Integer
Af.Enabled = True
I = 3
Af.Enabled = False
-> retoune 0,0207ms
merci pour ce(s) commentaire(s), j'en prend bonne note en attendant les suivants ;)
PCPT
Salut,
pour Le crash dans l'IDE, j'en suis conscient. il faut l'utiliser en OCX. il ne plante pas l'IDE lorsqu'il est compilé (je viens de vérifier).
pour "Let Interval", en effet, j'ai placé le "End If" un peu trop haut. je modifie çà, et je mettrais à jour après d'autres commentaires...
pour ceux qui veulent le changer de suite, il suffit de déplacer le "End If" juste avant le "End Property"
Pour "Err.Raise", je ne connais pas. on peut l'utiliser sans avoir à déclarer un "Event Error" perso? c'est juste pour savoir, j'aime bien ma manière de procéder tout de même :-p , avec légende + paramètres supplémentaires éventuels (même si c'est inutile pour ce cas de figure)
merci ....
(tu peux aussi noter si tu veux -_-)
PCPT
Attention cependant a la technique employée : VB est sensible aux procédures de rappel (CallBack) et crash si on presse par exemple le bouton STOP de l'IDE
Attention dans "Let Interval" si on réaffecte la même valeur, on se retrouve avec mInterval = 1
Pour l'erreur, tu peux utiliser Err.Raise 231 , "TypeTimer ne peut pas être changé l...."
mise à jour du Zip : OCX compilé fourni.
(le Projet_Sample est tout de même lié au projet non-compilé)
je crois que ce Timer peut servir à plus d'un...
j'attend vos retours ;)
merci
- Messages postés
-
13280
- Date d'inscription
- lundi 13 décembre 2004
- Statut
- Modérateur
- Dernière intervention
- 3 février 2018
41code -> parce que je suis dans les OCX depuis peu, c'est pour me faire la main.
parce qu'en classe, çà existe déjà.
pour vraiment remplacer le TimerVB, donc dans les outils ;)
(mais tu es le 2e à m'en faire la remarque)
distribution -> l'ocx compilé est fourni dans un fichier Release, je ne vois pas le problème de référencer un projet recompilable, à un projet exemple....
ou alors j'ai mal compris.... (?)
çà fait plaisir en tout cas
PCPT
Utile, vu le contrôle Timer de VB.
Code: 8/10
Pourquoi pas une classe plutôt qu'un OCX?
Distribution: 6/10
Editer le vbp pour les références, hum.
Pédagogie: 10/10
Bien les explications sur l'interface.
Interface: 10/10
Bon design!
Conclusion: un bon contrôle ActiveX.
- Messages postés
-
13280
- Date d'inscription
- lundi 13 décembre 2004
- Statut
- Modérateur
- Dernière intervention
- 3 février 2018
41peut-être m'y plongerais-je + un jour...
All -> zip mis à jour, avec la correction de l'intervalle (le "End If" trop haut).
et j'en ai profité pour le passer à 10 par défaut et 10 en cas d'erreur, en laissant la possibilité de le descendre jusqu'à 1 comme le Timer VB (même si il n'y en a pas d'utilité)
PCPT