[MFC]Les Controls d'une appli. basée sur Dialog ne sont plus graphiquement rafraichis

Windows XP / Visual C++ 2003 / MFC

Bonjour,
j'ai réalisé une application basée sur une Fenêtre de Dialogue, y ai incorporé des Controls divers, dont un Control principal qui est une Grid customisée ( ...du type Excel) dérivée d'une CWnd. Cette grille gère certains messages courants comme le clic-souris, le re-size, le déplacement de scroll-bars, etc...

Mon point est le suivant:
Après une certaine durée d'utilisation de l'application, et entre autres de manipulation sur la grille en question, les Controls de la fenêtre de Dialog ne sont plus graphiquement rafraichis, comme si mon application avait perdu la main sur ses Controls. Parfois il suffit de recliquer sur ces controls pour qu'ils réapparaissent graphiquement ... mais un plantage n'est jamais bien loin et ce plantage s'accompagne souvent du message

"Une resource ID n'est pas disponible" ... message à demi affiché d'ailleurs...

Je sais que sous les versions précédentes de Windows (98 et en deça) il fallait, si nécessaire, agrandir la zone mémoire de la liste des IDs des ressources graphiques. Mais j'ai lu également que sous XP cela n'est plus essentiel, XP proposant une zone mémoire virtuelle a priori infinie pour les ressources graphiques ....

J'ai également parallélisé (lancement de threads spécifiques) les tâches de calculs pour laisser le plus possible la main au rafraichissement écran et l'interaction machine-utilisateur.

Le problème reste entier.

Quelqu'un aurait il eu un problème similaire?

J'ai lu énormément de documentation sur la programmation Windows et les MFC ... mais il y a apparement des notions fondamentales que je ne maîtrise pas.
Existe t'il des ressources particulièrement intéressantes relatives à mon problème?

Merci pour l'attention que vous aurez bien voulu porter à mon message. :)

dbilem

salut,
si tu fais des boucles de traitement, l'interface peut ne plus être rafraichie.
mais bon ça ne devrait provoquer de plantage.
http://c.developpez.com/faq/vc/?page...rk#PumpMessage
tu as surveillé l'usage des ressources dans le gestionnaire de tache?
les ressources infinies sur xp j'ai un doute la dessus surtout sur les objets gui.
:D

Merci pour la promptitude de ta réponse.

A vrai dire le problème n'est pas un "rafraichissement retardé" du à la main mise d'une fonction sur la ressource cpu. Le gestionnaire des tâches montre une activité très faible en l'occurence.

L'application semble à un certain moment perdre les pédales au niveau de l'affichage, mais il m'est cependant possible, avant plantage, d'accéder à certains boutons, dont celui reliée à la fonction d'enregistrement des données. Le plantage intervient si je persiste dans l'utilisation du GUI...

Le plus drôle c'est que Visual C++ est incapable de me pointer une ligne de code après plantage, même en mode debug... ou bien si peut être une fois m'a t'il pointé un CPaintDC mal récupéré. Je me suis alors posé la question des DC, mais sans grand succès. Je me suis demandé s'il était possible que l'appli rentre à nouveau dans la fonction OnPaint de mon Control de grille customisée avant même d'en être sortie une première fois... Mais il parait absurde que deux messages WM_PAINT, issus de deux appels consécutifs à Invalidate(), ne soient pas traités en séquence...

Une question alors:
- peut il y avoir interférence néfaste des messages de réfraichissement qui aboutirait au décrochement par l'appli de certains handles graphiques, ou bien une incapacité à récupérer un DC d'une fenêtre? Un accès dénié à certaines ressources?

... j'avoue aborder des problématiques "bas niveau" windows qui m'échappent! ... c'est sans doute le risque majeur de s'en remettre totalement aux MFC .... on en occulte les fondamentaux Windows...

Ce type de plantage est difficile à réitérer. A vrai dire je n'arrive plus à faire bugger l'appli sur mon environnement de développement. Il intervient chez mon client après une bonne heure d'utilisation normale du logiciel ... comme si un effet d'accumulation (de quoi?) provoquait in fine le plantage.

...j'ai conscience de la dimension peu encourageante de mon problème.

Merci à ceux qui pourront éclairer ma lanterne

farscape, je lis ton doc sur les MFC au cas où ...

ton custom grille il sort d'ou ?
si tu travailles avec les DC ,tu fais bien une liberation apres usage ?
c'est valable pour tous les objets gdi utilisés (normalement c'est fait par l'objet MFC).
sinon ton probleme est trop vague pour donner des pistes de recherche.
tu as regarder les ressources dans le gestionnaire de taches comme je te l'ai demandé ?
surveille la mémoire utilisé ,et les objets gdi utilisés .

Enfin résolu!
ça a pris du temps et surtout un peu de chance pour déceler l'erreur.
Merci à farscape pour m'avoir indiqué la démarche.
Il s'agissait bien d'objets GDI créés mais non détruits, en l'occurence dans la fonction OnCtlColor() d'un tout petit contrôle, où un objet Brush était créé puis retourné afin de changer sa couleur de fond . Le message WM_CTLCOLOR est émis à chaque fois que le contrôle a besoin d'être réfraichi. La fréquence d'appel est considérable lorsque par exemple on fait glisser une autre fenêtre sur le contrôle en question. La limite des objets GDI possibles étant fixée par défaut à 10 000, lorsque ce nombre est atteint l'application ne peut plus rafraichir les éléments graphiques et finit par planter. Bien évidemment le problème arrive après une certaine durée indéfinie d'utilisation de l'application.
merci encore farscape.

dBilem