Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[MFC] UpdateAllViews et les Items

26 réponses
Avatar
TigrouMeow
Bonsoir,

J'ai deux questions sur les MFC, décidément je suis plein de
problèmes ces derniers temps.

Bon je tiens à parler un tout petit peu de l'architecture de mon
programme avant. Rien d'extraordinaire, une doc, des views
associés, et à côté de ça je lance un thread. Ce thread a des
impacts sur mon doc, il renseigne régulièrement des variables
qui s'y trouvent.

Maintenant j'ai deux questions.

1) Quand je fais un pDoc->UpdateAllViews(NULL) depuis
une de mes views, pas de problème. Par contre, si je l'appelle
depuis mon thread séparé, j'ai un "Debug Assertion Failed".

Voici le stacktrace si ça peut aider :
- mfc71d.dll!CWnd::AssertValid() Ligne 888 + 0x43 C++
- mfc71d.dll!CCtrlView::AssertValid() Ligne 563 C++
- WinTrace.exe!CListe::AssertValid() Ligne 25 C++
- mfc71d.dll!AfxAssertValidObject ...
- mfc71d.dll!CDocument::UpdateAllViews ...

Pour info, le pointeur vers pDoc et le même que ça soit dans
mon thread que dans mes views, j'ai vérifié sa valeur et il n'y
a aucun problème.

2) Dans une TreeView et une ListView, est-il possible de
spécifier une couleur spéciale pour un certain item ? Si oui,
bien sur, comment ? :)

Je vous remercie beaucoup, surtout surtout sur la 1ère
question car ça me bloque vraiment dans ma progression,
sinon la deuxième question je trouverai ça génial si il y
avait un moyen pas compliqué (sans recoder ou modifier
un widget...).

--
Meow ;o)

10 réponses

1 2 3
Avatar
Patrick Philippot
TigrouMeow wrote:
1) Quand je fais un pDoc->UpdateAllViews(NULL) depuis
une de mes views, pas de problème. Par contre, si je l'appelle
depuis mon thread séparé, j'ai un "Debug Assertion Failed".



Bonjour,

Dans les MFC, les pointeurs vers une CWnd (ou une classe dérivée de
CWnd) ne peuvent pas être utilisés depuis n'importe quel thread. Ceci
est dû au fait que les tables qui associent un handle de fenêtre à un
pointeur vers une classe de type CWnd sont des données propres à un
thread.

Reprise d'une de mes réponses sur le même sujet:

"
Je crois que vous êtes tombé dans un piège classique des MFC. On ne peut
pas utiliser dans un thread un pointeur vers une classe dérivée de CWnd
si l'instance de cette classe a été créée dans un autre thread. Cela est
dû à la manière dont les MFC stockent les maps qui font la
correspondance entre le handle de la fenêtre et le pointeur vers
l'instance de la classe qui représente la fenêtre. La plupart du temps,
ces maps sont locales au thread créateur. Ce qui veut dire en clair
qu'un pointeur vers une class CWnd ou dérivée instanciée dans un thread
ne peut pas être passé à un autre thread.<snip>

Ce qu'il faut faire c'est passer le handle de la fenêtre à l'autre
thread, recréer une instance de la classe locale au thread destinataire
(cette instanciation peut se faire grâce à la méthode
CWnd::FromHandlePermanent) et utiliser cette instance pour manipuler la
fenêtre. Il y a aura donc à ce moment, 2 instances de CWnd ou dérivée
pointant sur la même fenêtre, une dans chaque thread.

Quand vous n'avez plus besoin de l'instance de CWnd créée dans le thread
secondaire, utilisez Detach avant que l'objet ne soit détruit pour
éviter la destruction de la fenêtre.
"
Dans votre cas, des manipulations supplémentaires peuvent être
nécessaires.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Avatar
TigrouMeow
"Patrick Philippot" a écrit dans le
message de news: d35arb$2isr$
TigrouMeow wrote:
1) Quand je fais un pDoc->UpdateAllViews(NULL) depuis
une de mes views, pas de problème. Par contre, si je l'appelle
depuis mon thread séparé, j'ai un "Debug Assertion Failed".



Bonjour,

Dans les MFC, les pointeurs vers une CWnd (ou une classe dérivée de CWnd)
ne peuvent pas être utilisés depuis n'importe quel thread. Ceci est dû au
fait que les tables qui associent un handle de fenêtre à un pointeur vers
une classe de type CWnd sont des données propres à un thread.

Reprise d'une de mes réponses sur le même sujet:

"
Je crois que vous êtes tombé dans un piège classique des MFC. On ne peut
pas utiliser dans un thread un pointeur vers une classe dérivée de CWnd si
l'instance de cette classe a été créée dans un autre thread. Cela est dû à
la manière dont les MFC stockent les maps qui font la correspondance entre
le handle de la fenêtre et le pointeur vers l'instance de la classe qui
représente la fenêtre. La plupart du temps, ces maps sont locales au
thread créateur. Ce qui veut dire en clair qu'un pointeur vers une class
CWnd ou dérivée instanciée dans un thread ne peut pas être passé à un
autre thread.<snip>

Ce qu'il faut faire c'est passer le handle de la fenêtre à l'autre thread,
recréer une instance de la classe locale au thread destinataire
(cette instanciation peut se faire grâce à la méthode
CWnd::FromHandlePermanent) et utiliser cette instance pour manipuler la
fenêtre. Il y a aura donc à ce moment, 2 instances de CWnd ou dérivée
pointant sur la même fenêtre, une dans chaque thread.

Quand vous n'avez plus besoin de l'instance de CWnd créée dans le thread
secondaire, utilisez Detach avant que l'objet ne soit détruit pour
éviter la destruction de la fenêtre.
"
Dans votre cas, des manipulations supplémentaires peuvent être
nécessaires.



Merci :) Je pense à peu près avoir compris, là j'essaye de l'implémenter
mais c'est pas encore gagné...
Par contre, si je veux utiliser mon document depuis mon thread séparé,
je fais comment ? Car j'aimerais bien pouvoir faire des UpdateAllViews
à partir de lui, et vu que c'est lui qui contient toutes mes données...
J'ai regardé mais les docs n'ont pas de FromHandlePermanent ou
d'équivalent...
Avatar
TigrouMeow
"TigrouMeow" a écrit dans le message de
news: 4256ad81$0$6818$
"Patrick Philippot" a écrit dans le
message de news: d35arb$2isr$
TigrouMeow wrote:
1) Quand je fais un pDoc->UpdateAllViews(NULL) depuis
une de mes views, pas de problème. Par contre, si je l'appelle
depuis mon thread séparé, j'ai un "Debug Assertion Failed".



Bonjour,

Dans les MFC, les pointeurs vers une CWnd (ou une classe dérivée de CWnd)
ne peuvent pas être utilisés depuis n'importe quel thread. Ceci est dû au
fait que les tables qui associent un handle de fenêtre à un pointeur vers
une classe de type CWnd sont des données propres à un thread.

Reprise d'une de mes réponses sur le même sujet:

"
Je crois que vous êtes tombé dans un piège classique des MFC. On ne peut
pas utiliser dans un thread un pointeur vers une classe dérivée de CWnd
si l'instance de cette classe a été créée dans un autre thread. Cela est
dû à la manière dont les MFC stockent les maps qui font la correspondance
entre le handle de la fenêtre et le pointeur vers l'instance de la classe
qui représente la fenêtre. La plupart du temps, ces maps sont locales au
thread créateur. Ce qui veut dire en clair qu'un pointeur vers une class
CWnd ou dérivée instanciée dans un thread ne peut pas être passé à un
autre thread.<snip>

Ce qu'il faut faire c'est passer le handle de la fenêtre à l'autre
thread, recréer une instance de la classe locale au thread destinataire
(cette instanciation peut se faire grâce à la méthode
CWnd::FromHandlePermanent) et utiliser cette instance pour manipuler la
fenêtre. Il y a aura donc à ce moment, 2 instances de CWnd ou dérivée
pointant sur la même fenêtre, une dans chaque thread.

Quand vous n'avez plus besoin de l'instance de CWnd créée dans le thread
secondaire, utilisez Detach avant que l'objet ne soit détruit pour
éviter la destruction de la fenêtre.
"
Dans votre cas, des manipulations supplémentaires peuvent être
nécessaires.



Merci :) Je pense à peu près avoir compris, là j'essaye de l'implémenter
mais c'est pas encore gagné...
Par contre, si je veux utiliser mon document depuis mon thread séparé,
je fais comment ? Car j'aimerais bien pouvoir faire des UpdateAllViews
à partir de lui, et vu que c'est lui qui contient toutes mes données...
J'ai regardé mais les docs n'ont pas de FromHandlePermanent ou
d'équivalent...



En fait, pour simplifier, j'ai mon Doc et des views associés.
J'ai un thread à part qui tourne et qui récupère des infos sur le
système (en gros). Quand il a des infos, il met à jour des variables
du Doc, et il fait appel à un UpdateAllViews.
Voilà c'est tout ce que je veux faire :)
Avatar
Patrick Philippot
> En fait, pour simplifier, j'ai mon Doc et des views associés.
J'ai un thread à part qui tourne et qui récupère des infos sur le
système (en gros). Quand il a des infos, il met à jour des variables
du Doc, et il fait appel à un UpdateAllViews.
Voilà c'est tout ce que je veux faire :)



Il y a plus d'infos sur ce problème en général sur cette page:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_Multithreading.3a_.Programming_Tips.asp

La solution qui me paraît évidente, c'est tout simplement d'envoyer
(poster) depuis le thread un message privé à la fenêtre principale (en
passant éventuellement en paramètre le pointeur sur le document). Sur
réception du message, UpdateAllViews est appelé sur le document passé en
paramètre.

Il y a un exemple similaire là:

http://www.mvps.org/vcfaq/mfc/12.htm

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Avatar
TigrouMeow
"Patrick Philippot" a écrit dans le
message de news: d36dft$319o$
En fait, pour simplifier, j'ai mon Doc et des views associés.
J'ai un thread à part qui tourne et qui récupère des infos sur le
système (en gros). Quand il a des infos, il met à jour des variables
du Doc, et il fait appel à un UpdateAllViews.
Voilà c'est tout ce que je veux faire :)



Il y a plus d'infos sur ce problème en général sur cette page:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_Multithreading.3a_.Programming_Tips.asp

La solution qui me paraît évidente, c'est tout simplement d'envoyer
(poster) depuis le thread un message privé à la fenêtre principale (en
passant éventuellement en paramètre le pointeur sur le document). Sur
réception du message, UpdateAllViews est appelé sur le document passé en
paramètre.



En fait j'ai surement un manque de connaissance MFC à côté.
C'est à propos de cette "fenêtre principale". Quelle est-elle ? Est-ce
ma MainFrame ?

Si c'est la MainFrame, il n'est pas possible de faire des
UpdateAllViews... et je ne sais pas du tout comment
accéder au doc non plus depuis celle-ci...

Désolé je suis vraiment en galère ;)
Avatar
Patrick Philippot
TigrouMeow wrote:
La solution qui me paraît évidente, c'est tout simplement d'envoyer
(poster) depuis le thread un message privé à la fenêtre principale
(en passant éventuellement en paramètre le pointeur sur le
document). Sur réception du message, UpdateAllViews est appelé sur
le document passé en paramètre.



En fait j'ai surement un manque de connaissance MFC à côté.



Il me semble en effet, sauf votre respect, qu'avant de vous lancer dans
des opérations de multithreading toujours délicates sous les MFC, il
vous faudrait "asseoir" quelque peu votre connaissance de cette
bibliothèque :-) . Comme je l'ai expliqué plus haut, le multithreading
sous les MFC demande une connaissance de certains phénomènes parasites
qu'il faut maîtriser pour éviter les problèmes (notamment le
fonctionnement des messages maps et la manière dont sont gérées les
associations handle de fenêtre / pointeur vers la classe
correspondante). La lecture d'un bon bouqin sur les MFC comme le
Blaszczak (Professional MFC with Visual C++ ), le Prosise ou MFC
Internals de Shepherd et Wingo vous sera utile (voire indispensable).

Je sais que c'est idiot mais "commencer par le commencement" peut
parfois (que dis-je, tout le temps) faire gagner énormément de temps.

C'est à propos de cette "fenêtre principale". Quelle est-elle ? Est-ce
ma MainFrame ?



Je ne connais pas l'appli mais oui, a priori.

Si c'est la MainFrame, il n'est pas possible de faire des
UpdateAllViews... et je ne sais pas du tout comment
accéder au doc non plus depuis celle-ci...



Si vous ne maîtrisez pas cette architecture et si vous ne savez pas
comment lister les documents existants depuis la mainframe, le mieux est
peut-être d'envoyer un message de commande (au lieu d'un message privé)
et de traiter ce message au niveau du/des document(s). Par exemple:

#define MACOMMANDE_UPDATE nnnnn // A vous de décider d'une valeur
unique pour la commande

Dans le thread, on suppose que vous avez récupéré le pointeur vers la
mainframe avec AfxGetMainWnd à un moment donné et stocké cette valeur
dans une variable de classe (par exemple m_pMainWnd):

m_pMainWnd->PostMessage(WM_COM­MAND, MAKEWPARAM((MACOMMANDE_UPDATE , 0),
0);

Dans la classe document, déclarez :

void OnDoUpdateAll();

Dans la message map, de la classe document, ajoutez:

ON_COMMAND(MACOMMANDE_UPDATE, OnDoUpdateAll)

Dans l'implémentation de OnDoUpdateAll, faites l'appel à UpdateAllViews.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Avatar
TigrouMeow
"Patrick Philippot" a écrit dans le
message de news: d384e3$l3h$
TigrouMeow wrote:
La solution qui me paraît évidente, c'est tout simplement d'envoyer
(poster) depuis le thread un message privé à la fenêtre principale
(en passant éventuellement en paramètre le pointeur sur le
document). Sur réception du message, UpdateAllViews est appelé sur
le document passé en paramètre.



En fait j'ai surement un manque de connaissance MFC à côté.



Il me semble en effet, sauf votre respect, qu'avant de vous lancer dans
des opérations de multithreading toujours délicates sous les MFC, il vous
faudrait "asseoir" quelque peu votre connaissance de cette bibliothèque
:-) . Comme je l'ai expliqué plus haut, le multithreading sous les MFC
demande une connaissance de certains phénomènes parasites qu'il faut
maîtriser pour éviter les problèmes (notamment le fonctionnement des
messages maps et la manière dont sont gérées les associations handle de
fenêtre / pointeur vers la classe correspondante). La lecture d'un bon
bouqin sur les MFC comme le Blaszczak (Professional MFC with Visual C++ ),
le Prosise ou MFC Internals de Shepherd et Wingo vous sera utile (voire
indispensable).

Je sais que c'est idiot mais "commencer par le commencement" peut parfois
(que dis-je, tout le temps) faire gagner énormément de temps.

C'est à propos de cette "fenêtre principale". Quelle est-elle ? Est-ce
ma MainFrame ?



Je ne connais pas l'appli mais oui, a priori.

Si c'est la MainFrame, il n'est pas possible de faire des
UpdateAllViews... et je ne sais pas du tout comment
accéder au doc non plus depuis celle-ci...



Si vous ne maîtrisez pas cette architecture et si vous ne savez pas
comment lister les documents existants depuis la mainframe, le mieux est
peut-être d'envoyer un message de commande (au lieu d'un message privé) et
de traiter ce message au niveau du/des document(s). Par exemple:

#define MACOMMANDE_UPDATE nnnnn // A vous de décider d'une valeur
unique pour la commande

Dans le thread, on suppose que vous avez récupéré le pointeur vers la
mainframe avec AfxGetMainWnd à un moment donné et stocké cette valeur dans
une variable de classe (par exemple m_pMainWnd):

m_pMainWnd->PostMessage(WM_COM­MAND, MAKEWPARAM((MACOMMANDE_UPDATE , 0),
0);

Dans la classe document, déclarez :

void OnDoUpdateAll();

Dans la message map, de la classe document, ajoutez:

ON_COMMAND(MACOMMANDE_UPDATE, OnDoUpdateAll)

Dans l'implémentation de OnDoUpdateAll, faites l'appel à UpdateAllViews.



Tout d'abord merci beaucoup pour votre aide :)
Mais décidément, j'arrête pas d'avoir des problèmes et rien ne marche,
j'ai pourtant lu attentivement tout ce que vous avez écrit, et la MSDN
et j'ai cherché partout sur Google...

J'ai essayé d'implémenté comme vous me l'avez dit, donc dans mon doc
je trouve un :
BEGIN_MESSAGE_MAP(CWinTraceDoc, CDocument)
ON_COMMAND(LIBRARY_ADD, AddLibrary)
END_MESSAGE_MAP()

Et la déclaration de la fonction :
void CWinTraceDoc::AddLibrairy()
{
TRACE("AddLibraryn");
}

Et dans l'include du Doc je déclare le prototype comme ça :
afx_msg void AddLibrairy();

Il me sort une erreur :
AddLibrary : identificateur non déclaré.

Je comprend vraiment plus rien là :(
Suis désolé d'être aussi nul, mais j'ai de plus en plus l'impression
que la MFC est très très mal faite de partout, vu que j'ai jamais
eu de problèmes aussi étonnant avec les WinForms ni Gtk...
Avatar
TigrouMeow
"TigrouMeow" a écrit dans le message de
news: 4257c73b$0$6804$
"Patrick Philippot" a écrit dans le
message de news: d384e3$l3h$
TigrouMeow wrote:
La solution qui me paraît évidente, c'est tout simplement d'envoyer
(poster) depuis le thread un message privé à la fenêtre principale
(en passant éventuellement en paramètre le pointeur sur le
document). Sur réception du message, UpdateAllViews est appelé sur
le document passé en paramètre.



En fait j'ai surement un manque de connaissance MFC à côté.



Il me semble en effet, sauf votre respect, qu'avant de vous lancer dans
des opérations de multithreading toujours délicates sous les MFC, il vous
faudrait "asseoir" quelque peu votre connaissance de cette bibliothèque
:-) . Comme je l'ai expliqué plus haut, le multithreading sous les MFC
demande une connaissance de certains phénomènes parasites qu'il faut
maîtriser pour éviter les problèmes (notamment le fonctionnement des
messages maps et la manière dont sont gérées les associations handle de
fenêtre / pointeur vers la classe correspondante). La lecture d'un bon
bouqin sur les MFC comme le Blaszczak (Professional MFC with Visual
C++ ), le Prosise ou MFC Internals de Shepherd et Wingo vous sera utile
(voire indispensable).

Je sais que c'est idiot mais "commencer par le commencement" peut parfois
(que dis-je, tout le temps) faire gagner énormément de temps.

C'est à propos de cette "fenêtre principale". Quelle est-elle ? Est-ce
ma MainFrame ?



Je ne connais pas l'appli mais oui, a priori.

Si c'est la MainFrame, il n'est pas possible de faire des
UpdateAllViews... et je ne sais pas du tout comment
accéder au doc non plus depuis celle-ci...



Si vous ne maîtrisez pas cette architecture et si vous ne savez pas
comment lister les documents existants depuis la mainframe, le mieux est
peut-être d'envoyer un message de commande (au lieu d'un message privé)
et de traiter ce message au niveau du/des document(s). Par exemple:

#define MACOMMANDE_UPDATE nnnnn // A vous de décider d'une valeur
unique pour la commande

Dans le thread, on suppose que vous avez récupéré le pointeur vers la
mainframe avec AfxGetMainWnd à un moment donné et stocké cette valeur
dans une variable de classe (par exemple m_pMainWnd):

m_pMainWnd->PostMessage(WM_COM­MAND, MAKEWPARAM((MACOMMANDE_UPDATE , 0),
0);

Dans la classe document, déclarez :

void OnDoUpdateAll();

Dans la message map, de la classe document, ajoutez:

ON_COMMAND(MACOMMANDE_UPDATE, OnDoUpdateAll)

Dans l'implémentation de OnDoUpdateAll, faites l'appel à UpdateAllViews.



Tout d'abord merci beaucoup pour votre aide :)
Mais décidément, j'arrête pas d'avoir des problèmes et rien ne marche,
j'ai pourtant lu attentivement tout ce que vous avez écrit, et la MSDN
et j'ai cherché partout sur Google...

J'ai essayé d'implémenté comme vous me l'avez dit, donc dans mon doc
je trouve un :
BEGIN_MESSAGE_MAP(CWinTraceDoc, CDocument)
ON_COMMAND(LIBRARY_ADD, AddLibrary)
END_MESSAGE_MAP()

Et la déclaration de la fonction :
void CWinTraceDoc::AddLibrairy()
{
TRACE("AddLibraryn");
}

Et dans l'include du Doc je déclare le prototype comme ça :
afx_msg void AddLibrairy();

Il me sort une erreur :
AddLibrary : identificateur non déclaré.

Je comprend vraiment plus rien là :(
Suis désolé d'être aussi nul, mais j'ai de plus en plus l'impression
que la MFC est très très mal faite de partout, vu que j'ai jamais
eu de problèmes aussi étonnant avec les WinForms ni Gtk...



Bon je reviens sans attendre de réponse :) Finalement je me dis
que ça serait peut-être mieux de travailler avec des handle plutot
que d'envoyer des messages partout, vu que je met des données à
jour et tout ça.

Ce que j'ai tenté de faire (et qui ne marche bien sur pas lol), c'est
avant de créer mon thread de récupérer le handle de ma fenêtre
en faisant un
GetSafeHwnd() dessus, ensuite j'enregistre cet valeur dans le thread,
et le thread une fois exécuté fait un
_wJournal->FromHandlePermanent(wnd) ou encore un
_wJournal->Attach(wnd)
(je sais pas la différence... MSDN dit très explicitement qu'il faut faire
attach pour que l'objet existe plus longtemps que le thread, ça veut rien
dire pour moi enfin...). Bon Attach directement, ça plante, sinon avec
FromHandlePermanent ça passe. Si après j'ose utiliser le
_wJournal->MyFunction (qui contient un UpdateAllWindows en passant
par le document par exemple) ça plante. C'est pas censé s'exécuter dans
l'autre thread pourtant à ce moment là ?

J'y comprends rieeeeeeeeeeeeen, merci une fois de plus de m'aider...
Avatar
Patrick Philippot
TigrouMeow wrote:
J'ai essayé d'implémenté comme vous me l'avez dit, donc dans mon doc
je trouve un :
BEGIN_MESSAGE_MAP(CWinTraceDoc, CDocument)
ON_COMMAND(LIBRARY_ADD, AddLibrary)
END_MESSAGE_MAP()

Et la déclaration de la fonction :
void CWinTraceDoc::AddLibrairy()
{
TRACE("AddLibraryn");
}

Et dans l'include du Doc je déclare le prototype comme ça :
afx_msg void AddLibrairy();

Il me sort une erreur :
AddLibrary : identificateur non déclaré.



... à moins que AddLibrairy ne soit pas une faute de frappe, je ne vois
pas...

Suis désolé d'être aussi nul,



Il me semble surtout que vous voulez aller plus vite que la musique.
Quand j'étais petit, on apprenait l'alphabet en commençant par le A et
on lisait les livres et les documentations en commençant par le chapitre
1. On apprenait les bases puis on construisait dessus. Il paraît que les
choses ne fonctionnent plus comme ça de nos jours, qu'il faut être
productif, gagner du temps, aller vite et construire les gratte-ciel en
commençant par le toit mais c'est dommage, je trouve ça bien pratique,
comme méthode de travail :-) .

mais j'ai de plus en plus l'impression
que la MFC est très très mal faite de partout,



Comme je le disais, il faut d'abord se former à son fonctionnement. Les
MFC ne sont pas l'idéal comparées à d'autres frameworks (comme OWL) mais
elles sont plus solides qu'on ne le dit souvent. En termes de
programmation objet, le design est assez limite mais il ne faut pas
oublier que les MFC ont été conçues pour VC ++ 16-bit et que les
programmes écrits proprement il y a 13 ans pour VC++ 1.0 peuvent être
repris dan sla version actuelle pratiquement tels quels. C'est un
avantage que beaucoup d'entreprises ont apprécié mais cela a été fait au
proix de qulques concessions.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Avatar
Patrick Philippot
TigrouMeow wrote:
J'y comprends rieeeeeeeeeeeeen, merci une fois de plus de m'aider...



La méthode que je vous ai proposée doit fonctionner. Mais cela suppose
que vous compreniez ce que vous faites, sinon il faudra que vous dicte
le code. On en revient au débat de départ: si vous ne maîtrisez pas les
bases des MFC, on risque de tourner en rond.

C'est un projet urgent ou bien vous avez le temps de prendre le temps?

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
1 2 3