Application.DoEvents() [Résolu]

cs_Micro 9 Messages postés vendredi 28 décembre 2001Date d'inscription 7 septembre 2009 Dernière intervention - 26 févr. 2008 à 10:03 - Dernière réponse : cs_Micro 9 Messages postés vendredi 28 décembre 2001Date d'inscription 7 septembre 2009 Dernière intervention
- 13 avril 2008 à 22:11
Bonjour à tous,
J'aurais besoin d'un petit coup de main concernant la méthode Application.DoEvents().
Je programme en C#sous VS2003 et j'ai un petit souci car dans mon appli, j'ai 3 Threads qui tournent assez vite (1 à 200ms pour rafraichir l'IHM, 1 à 100ms pour traiter les données, et 1 à 50ms pour gérer les échanges sur la voie série).

Mon souci est le suivant, dès que je place un Application.DoEvents() dans un des Threads, mon appli grossit en mémoire petit à petit (elle prend environ 7Mo sur 8 heures).
Jusqu'à maintenant, j'ai réussit à me passer de ce fichu Application.DoEvents() mais là, je n'ai pas le choix car sinon, j'ai des soucis de rafraichissement de l'IHM et surtout de prise en compte des évènements de la souris.
Mon appli est censée tournée 24h/24h 7j/7j donc ce problème est bloquant.

Quelqu'un aurait-il une solution à ce problème ?

P.S : j'ai essayé de placer un System.GC.Collect() juste derrière le Application.DoEvents() pour forcer le Garbage Collector à libérer la mémoire allouée pour la sauvegarde de contexte liée au Application.DoEvents() mais c'est pareil.

Merci d'avance.

Micro
Afficher la suite 

Votre réponse

4 réponses

Meilleure réponse
sebmafate 4947 Messages postés lundi 17 février 2003Date d'inscription 14 février 2014 Dernière intervention - 26 févr. 2008 à 14:04
3
Merci
en même, je ne suis pas sûr que le meilleur moyen soit de rafraichir l'IHM toutes les xxx ms...
pourquoi ne pas scruter les modifications de données et déclencher un évènement pour mettre à jour l'écran ?

c'est plus logique et en plus ça prendrai moins de ressource.

Sébastien FERRAND (blog)
Consultant Indépendant
[Microsoft Visual C# MVP]

Merci sebmafate 3

Avec quelques mots c'est encore mieux Ajouter un commentaire

Codes Sources a aidé 74 internautes ce mois-ci

Commenter la réponse de sebmafate
Nikoui 794 Messages postés vendredi 24 septembre 2004Date d'inscription 19 août 2008 Dernière intervention - 26 févr. 2008 à 10:52
0
Merci
Quand tu dis qu'elle prend 7Mo en 8heures, tu as calculé ça en faisant une différence entre la taille de départ et la taille 8h après, ou tu as observé une progression linéaire de 7Mo en 8h?

Parce que normalement avec le garbage collector, l'empreinte mémoire de ton application va grossir plus ou moins régulièrement, puis chuter à un moment ou à un autre, pour recommencer à grossir, et ainsi de suite (autrement dit faire des mesures ponctuelles de l'utilisation mémoire n'est pas suffisant, c'est la courbe d'évolution qu'il faut suivre - ou faire une moyenne sur un temps très long (mais 8h devrait être sufisant)).

Forcer le GC.Collect n'est pas une bonne idée : la seule raison qui devrait pousser un développeur à effectuer cela, c'est lorsqu'il se prépare à effectuer un traitement qui va consommer énormément de mémoire et/ou ne doit pas être ralenti au cas où le GC se "déclenche" pendant le traitement. Dans ton cas, tu veux (si j'ai bien compris) t'assurer que ton application puisse tourner 24/24, et tu peux donc entièrement te reposer sur le GC, puisqu'il va justement pouvoir "s'exprimer à sa guise" et gérer la mémoire comme il le faut sur le long terme.

Concernant le DoEvents, il est possible qu'il provoque une fuite mémoire (mais je pense que dans ce cas il doit déjà exister quelques post sur le net à ce sujet). Sinon il est possible aussi que le DoEvents force l'appel de certaines de tes méthodes (traitements d'évènement graphiques, Inputs, etc) dont l'une pourrait être à l'origine de la fuite (si fuite il y a).

Au pire, pas moyen de se passer du DoEvents? (en modifiant peut être l'organisation de tes threads, en jouant sur les priorités, etc ?)

<hr size="2" width="100%" />
Working as designed
www.nikoui.fr
Commenter la réponse de Nikoui
cs_Micro 9 Messages postés vendredi 28 décembre 2001Date d'inscription 7 septembre 2009 Dernière intervention - 26 févr. 2008 à 17:31
0
Merci
Salut Nikoui,
J'ai effectivement fait une mesure au bout de 8 heures ce qui m'a conduit à cette conclusion.
J'ai fait des essais avec aucun Application.DoEvents() dans le code et au bout d'une huitaine d'heures, l'appli n'a pris tout au plus que quelques centaines de kilo.
J'ai également surveillé la taille de l'appli pendant une durée d'environ 20 minutes et je me suis rendu compte qu'avec la Application.DoEvents() dans  le code, il régulièrement (environ une fois par seconde) des allocations mémoire sur le Heap (vu avec Process Explorer).


Pour le GC.Collect(), je suis d'accord avec toi, c'était en désespoir de cause


Je vais tester la solution Sebmafate qui effectivement paraît beaucoup plus "propre".

Merci beaucoup pour vos réponses, je vous tiens informé.

Micro
Commenter la réponse de cs_Micro
cs_Micro 9 Messages postés vendredi 28 décembre 2001Date d'inscription 7 septembre 2009 Dernière intervention - 13 avril 2008 à 22:11
0
Merci
Bonjour,
Me revoilà (désolé pour le retard), la solution de Sebmafate a fonctionné.
Plus aucun souci de ressources mémoire.

Merci encore pour le coup de main.

Micro
Commenter la réponse de cs_Micro

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.