Problème d'affichage dans une fenetre CDialog: DoModal!

Salut,

Bonh peut etre le titre de la discussion n'est pas très explicite!

Alors, je souhaite afficher des trace en temps réel(lors de l'éxécution d'un programme). Quand l'utilisateur click sur le bouton oui (oui pour dire qu'on souhaite visualiser les traces en temps réel) une fenetre, créée dynamiquement s'affiche ayant un CEdit; c'est dans ce CEdit qu'on va afficher les trace.

Voici le bout de code qui le fait:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

if (TRACE_EN_TEMPS_REEL == 1) { //tester si la fenetre a été déjà créée if (premiereFois == 0) { AfxMessageBox("On va afficher la fenetre"); dlg->DoModal(); //Pour dire que le DoModal a été déjà appelé premiereFois = 1; } AfxMessageBox("avant l'appel de afficherTexte"); dlg->afficherTrace(chMessage); }

---

Ce qui est sur est que j'arrive à afficher la fenetre dlg, mais après plus rien: j'ai l'impression que l'exécution du prog s'arrete au niveau de la ligne "dlg->DoModal();". La preuve est que la ligne en bleu ne fait rien!

Je pense que c'est un probleme lié au fait que la fenetre est modale. Je suis en train de me renseigner sur les fenetres non modales mais je en vois pas comment l'utiliser dans mon cas.

Je m'explique d'avantage : le bout de code ci-dessus doit etre appelé chaque fois qu'on écrit une trace (il se trouve dans le coprs d'une boucle while) mais dès le premier appel à ce code, qui correspond d'ailleurs à l'affichage de la fenetre dlg, tout s'arrete et je ne peux meme pas écrire la premiere trace :aie:

Quelqu'un peut m'aider?
Merci pour toute aide

salut,
ben oui ,si c'est modale ça s'arrête à l'exécution de domodal, et ça reprend quand la dialogue se ferme...
il te faut créer une dialogue non modale, faq: http://cpp.developpez.com/faq/vc/?pa...CreateModeless
et
http://cpp.developpez.com/faq/vc/?pa...gPostNcDestroy

Merci pour ta réponse!

Je suis sur cette piste depuis un moment mais j'ai un pb avec le IDD. Ma fenetre je la crée dynamiquement, donc le IDD je ne l'ai pas :aie:.
J'ai regardé sur le site de microsoft, et je vois qu'au lien de passer le IDD on peut se referer à la fenetre par son titre dont je dispose mais la méthode Create échoue 8O

Code:

---

1 2 3 4 5

pDlg = new CMyDlg(this); pDlg->Create(CMyDlg ::IDD,this); pDlg->ShowWindow(SW_SHOW);

---

et alors elle est bien associée a une ressource non ?

Bein non: je la crée dynamiquement sans ressource en utilisant d'ailleurs le code disponible dans la FAQ :

http://cpp.developpez.com/faq/vc/?pa...wToMakeDynamic

ok , alors ils faut modifier pour utiliser CreateIndirect a la place de InitModalIndirect

c'est bon ça marche, je suis arrivé à afficher des traces mais y a un petit souci :aie:

La creation échoue Create renvoie FALSE, la preueve le message "Error creating Dialog" est affiché mais juste après, quand on click sur le bouton ok du MessageBox, la fenetre est affichée 8O8O je ne comprends pas.
Est ce que quelqu'un a une explication??
Voici le code:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

if (TRACE_EN_TEMPS_REEL == 1) { if (premiereFois == 0) { BOOL ret = dlg->Create("Charge_ccam: traces en temps reel",NULL); if(!ret) //La création échoue AfxMessageBox("Error creating Dialog"); //Mais la fenetre est affichée dlg->ShowWindow(SW_SHOW); premiereFois = 1; } //AfxMessageBox("avant l'appel de afficherTexte"); dlg->afficherTrace(chMessage); }

---

Merci

Résolu!
Une boulette de ma part :oops: : j'instancie la classe( dlg est l'instance de ma classe) avec un new et puis je fais un appel à Create sur dlg :aie::aie:
Il fallait pas faire le Create.

Citation:

---

Envoyé par vonemya

Résolu!
Une boulette de ma part :oops: : j'instancie la classe( dlg est l'instance de ma classe) avec un new et puis je fais un appel à Create sur dlg :aie::aie:
Il fallait pas faire le Create.

---

ben non ;)

Citation:

---

Envoyé par farscape

ok , alors ils faut modifier pour utiliser CreateIndirect a la place de InitModalIndirect

---

Re,

J'ai fait comme tu m'as dit. J'arrive à afficher les traces dans le CEdit de cette fenetre non modale.

Mais il y a un petit souci: si, quand les traces sont en train d'etre affcihées, je fais un click sur la fenetre (que ce soit sur un de ses boutons les ascenseurs du CEdit...) le programme plante. Ce qui se passe exactement est que me fenetre ne répond plus (devant le titre de ma fenetre s'ajoute le message "ne répond pas") et toute l'application plante :aie::aie: Ce pendant si pas de click tout va bien 8O8O


Est ce que quelqu'un a déjà rencontré un problème similaire???

J'explique vite fait le contexte de mon application:
J'ai fait un programme qui se connecte à une base de donné pour y faire des traitements. Maintenant je dois faire une interface pour recuperer les données me permettant de me connecter à la base et faire le traitement au meme temps je souhaite afficher les traces en temps réels: donc je fais appel à cette fenetre non modale pour y afficher les traces.

SVP c'est un peu urgent!

Citation:

---

Envoyé par vonemya

Re,

J'ai fait comme tu m'as dit. J'arrive à afficher les traces dans le CEdit de cette fenetre non modale.

Mais il y a un petit souci: si, quand les traces sont en train d'etre affcihées, je fais un click sur la fenetre (que ce soit sur un de ses boutons les ascenseurs du CEdit...) le programme plante. Ce qui se passe exactement est que me fenetre ne répond plus (devant le titre de ma fenetre s'ajoute le message "ne répond pas") et toute l'application plante :aie::aie: Ce pendant si pas de click tout va bien 8O8O


Est ce que quelqu'un a déjà rencontré un problème similaire???

J'explique vite fait le contexte de mon application:
J'ai fait un programme qui se connecte à une base de donné pour y faire des traitements. Maintenant je dois faire une interface pour recuperer les données me permettant de me connecter à la base et faire le traitement au meme temps je souhaite afficher les traces en temps réels: donc je fais appel à cette fenetre non modale pour y afficher les traces.

SVP c'est un peu urgent!

---

Je pense que le problème vient du fait que j'utilise uns eul processus alors que je dois utiliser des processus: le premier doit gérer les traitement effectués sur la base de données et le second doit gérer toutes les actions faite sur la fenetre d'affichage.

Je m'explique d'avantage: j'ai un programme qui tourne et qui affiche en temps réel des traces dans un CEdit d'une fenetre CDialog(non modale). En terme de code on a ceci:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

CfenetreAffichageTrace dlg;   while (...) { ...... ...... dlg.ecrireTrace(trace); ...... ...... }

---

Donc, quand on fait une action sur la fenetre dlg, alors que la boucle while est en train d'etre exécutée, le programme plante :aie:
Je me suis dit que peut etre il faut que je fasse un second processus qui gère la fenetre d'affichage. Est ce que quelqu'un peut me dire comment associer un processus à une fenetre pour gérer cette dernière?

le plus simple est d'avoir un thread de traitement qui met à jour une fenêtre.
sinon si c'est une boucle il faut laisser respirer l'application:
http://cpp.developpez.com/faq/vc/?pa...rk#PumpMessage

A vraidire le programme n'est pas une boucle, c'était juste pour simplifier mn explication: c'est un programme qui fait des traitement sur des bases de données et il y a un appel très fréquent à la méthode d'affichage des traces d'où l'analogie avec la boucle while.

Donc, il me faut un thread.

J'utilse la classe CWorkerThread (utilisation de AfxBeginThread) dont le code se trouve à la FAQ:
http://cpp.developpez.com/faq/vc/?pa...keWorkerThread

Le traitement qui se fait dans la méthode CWorkerThread::execute(), consiste en un appel à la méthode PumpMessages() qui est déclarée en tant que méthode public (non static) de la classe de ma fenetre.

Après avoir effectué des tests je suis sûr que la méthode PumpMessage s'execute en parallele avec les traitements de la base de données ce qui permet à la fenetre d'affichage de traiter les message.

Mais ça marche pas trop bien. PARFOIS, ça plante quand on click sur la fenetre. La seule explication que j'ai trouvé est que ceci serait dû à un accès concurent à l'instant dlg de la classe définissant la fenetre: le thread principal manipule cette instance en appelant la méthode dlg.ecrireTrace(trace) alors que au meme temps le thread que je crée manipule cette meme instance, au meme temps, en appelant dlg.PumpMessages().
Cela pourrait il etre la cause de ce crash?

Je suis en train d'essayer d'utiliser des verrous mais je ne sais pas si ça peut etre la (ou une) solution de mon problème.

Merci!

la dialogue ne doit pas être crée dans le thread
si l'appel se fait à partir d'une interface (dialogue par exemple).
tu créés ta dialogue non modal par un new ,tu stocks le pointeur dans l'interface en tant que donnée membre.
Au moment de l'AfxBeginThread tu fournis un pointeur de l'interface au thread.
dans le thread tu as donc accès a l'interface et au pointeur sur la dialogue non modale.

Le dialogue n'est pas créé dans le thread!

Le dialogue c'est une variable globale (créée par new)donc meme les méthodes de la classe CWorkerThread ont accès à cette instance, ce qui est équivalent à ce que tu me dis de faire. Mais ça plante!

ça plante en debug ? et en release?
si tu relis la faq :on ne peut accéder à des objets gui MFC à partir d'un thread de travail.
on utilisera un message privé, ça c'est la méthode standard.
la méthode non officielle :l'accès aux objets gui MFC ne fonctionne pas en debug mais en release oui.
d'ou ma question plus haut.

Citation:

---

Envoyé par farscape

ça plante en debug ? et en release?
si tu relis la faq :on ne peut accéder à des objets gui MFC à partir d'un thread de travail.
on utilisera un message privé, ça c'est la méthode standard.
la méthode non officielle :l'accès aux objets gui MFC ne fonctionne pas en debug mais en release oui.
d'ou ma question plus haut.

---

Mais qui va va éxecuter la routine correspondante au message privé envoyé. Est ce le thread qui l'a envoyé?

oui , faq: http://cpp.developpez.com/faq/vc/?pa...d#WorkerThread

Je veins d'adapter mon code pour utiliser les message privés.

Alors ce que je fais est le suivant:

Code:

---

1 2 3 4 5 6 7 8 9

BEGIN_MESSAGE_MAP(CMfenetre, CDialog) //{{AFX_MSG_MAP(CMfenetre) // NOTE: the ClassWizard will add message map macros here ON_BN_CLICKED(IDC_BOUTON, OnBouton) ON_MESSAGE(WM_TEST, OnQuitterModeAffichage) //}}AFX_MSG_MAP END_MESSAGE_MAP()

---

Donc quand on click sur le bouton IDC_BOUTON, on appelle la méthode OnBouton dont la definition est la suivante:*

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

void CMafenetre::OnBouton() { AfxBeginThread(TheThread,GetSafeHwnd(),THREAD_PRIORITY_NORMAL) ; }     //le définition de TheThread UINT TheThread(LPVOID pParam) { ::SendMessage((HWND)pParam,WM_TEST,0,0) ; return 0 ; }

---

Donc si je t'ai bien compris quand on click sur le bouton le message privé sera envoyé et on appellera donc OnQuitterModeAffichage qui sera exécuter par le thread crée par AfxBeginThread(). C ça??

Je viens de tester mais ça marche toujours pas: je click sur le bouton mais rien ne se passe et l'appli plante :cry::cry:

Peut etre que j'ai pas bien compris comment utiliser le message privé pour pallier à mon pb! Help please :cry::cry:

Je viens de regarder ça de plus près.
déjà le fait d'intercepter le message suivant

Code:

---

1 2 3

//OnBouton appelle AfxBeginThread(...) ON_BN_CLICKED(IDC_BOUTON, OnBouton)

---

nécessite un traitement par le processus en cours, le second n'étant pas encore crée par AfxBeginThread(). Donc ce message est mis en attente, d'autre message éttouferont l'application.
A mon avis le message privé ne peut pas résoudre mon problème à moins que je l'ai mal utilisé 8O


Tu disais un peu plus haut que "on ne peut accéder à des objets gui MFC à partir d'un thread de travail."
Je viens de faire un petit test: J'utilise la classe CWorkerThread (utilisation de AfxBeginThread)

Dans la routine execute() j'appelle la méthode PumpMessage() que j'ai déclaré en tant que fonction membre de la classe de ma fenetre(l'instance de cette dernière est globale donc on peut l'appeller dans execute()).
Avec un AfxMessageBox() placée à l'interieur du code de PumpMessages, je vois que cette dernière fonction est bel et bien appelée.
Cela prouve,donc, que j'ai accédé à l'objet MFC qui est l'instance dlg de la classe définissant ma fenetre d'affichage: l'appel dlg->PumpMessages() réussit.


Ainsi de cette manière, le thread que je crée appel en boucle (c la boucle de execute de CWorkerThread) le méthode PumpMessage() ce qui signifie, si je ne me trompe pas, que l'application "peut respirer"(traiter tous les message instantanément) mais ça plante toujours :cry::cry:


J'avous que je ne comprends plus rien 8O8O

Need Help Please!

je ne comprends pas ton problème.
quel est l'architecture du programme ? MDI /SDI / Dialog .
à partir de la fenêtre maitre tu lances une dialogue non modale générique (pourquoi générique?) ?
tu as un thread de travail , qui est lancé par qui ?
le thread met à jour la dialogue non modale ?
c'est bien ça?

Architecture du programme : Dialog!

A partir de la fenetre mère je lance une application qui se connecte à une base de données. Une fois la connexion établie on demande à l'utilisateur si il souhaite visualiser les traces en temps réel. Dans l'affirmatif je lance ma 2ème fenêtre(quipause problème).

Ensuite les traitement sur la base commencent et on voit les traces s'afficher dans ma fenetre(+ précisement dans son Cedit). Cette 2ème fenetre est non modale pour que le programme puisse continuer à s'éxecuter après son instanciation et appeler la méthode qui écrit les traces.

L'affichage se passe très bien!Mais quand tu click sur cette 2ème fenêtre (peut importe où, sur un de ces boutons, sur le CEdit....) alors que, au meme temps, le programme effectue des manip sur la base de données, y'a plus de reconstruction possible: cette fenetre n'as pas le temps de traiter les messages!!

Ce que je voulais faire pour permettre le traitement de ces messages (afin que ma fenetre ne "s'étouffe" pas) est créer un thread de travail qui appelle en boucle la méthode PumpMessage() pour "donner de l'air" à cette fenetre.
Je suis certain que le thread que je crée appele bel et bien PumpMessages() mais
le problème persiste: on dirait que l'appel de PumpMessages ne permet pas le traitement des messages correspondants aux clicks sur la zone client de la fenetre.

Voila j'espère que je me suis fait comprendre!

Merci d'avoir accordé autant d'attention à mon pb!

Voilà ça fait un moment que je galère maintenant, j'arrive pas à résoudre mon bug:cry::cry:
je vous passe mon code vous pouvez le télécharger à cette adresse:
http://www.megaupload.com/?d=4RRCS0JE
En fait, j'ai fait un code qui reproduit exactement mon bug. Lisez les commentaires du fichier Traitements.h pour bien assimuler la nature de mon bug!

Donc ,j'ai une CDialog CAffichageTraces contenant un bouton "Lancer". Quand on clique sur ce dernier, on appelle une fonction fctPrincipale() qui va lancer des traitements: en réalité ce sont des traitements sur une base de données mais pour faire simple, je les ai remplacés par des ::Sleep() sinon y'aura trop de code inutil pour la compréhension de mon bug.

FctPrincipale() instancie la classe CfenetreLog, l'instance est dlg, elle est non modale, qui est en fait déclarée en tant que variable globale (déclarée dans Traitements.cpp)
Une fois instanciée, la fenetre s'affiche et au fur et à mesure que le programme s'exécute on y écrit des traces.
Lors de l'affichage(donc quand les traitements sont en cours) si vous touchez à cette fenetre dlg, elle plante, plus de reconstruction possible, on dirait qu'elle ne trouve pas le temps de "respirer" (=de traiter les messages)

Compilez ce code et exécutez le et vous allez mieux assimiler mon problème.

Comment résoudre ce bug??
Si vous avez des questions n'hésitez pas!

Merci pour votre aide!

NB: mes dialog sont crées dynamiquement sans ressources!

attention chaque thread a sa propre pompe a message !!!

appeler PumpMessage() dans un thread pour faire "respirer" un autre thread est impossible ...

T'es pas forcément obligé de faire un autre thread, tout depend bien sur de comment est géré ton traitement sur les bases de données.

Moi je ferais un seul et unique thread, et le traitement sur les BDD se fera dans CWinApp::OnIdle(). --> remplacer CWinApp par la classe dérivée du projet.

OnIdle() est appelé lorsque la pompe a message est vide, de là tu peux faire un traitement spécifique, mais attention il faut rendre la main régulierement sinon l'appli sera figée. --> Il faut donc "sequencer" le travail a faire par petit paquet pas trop long en terme de temps d'execution.

c'est la methode la plus simple :king:

@+

Sinon il y a la methode inverse:

au lieu que ça soit les MFC qui appelle ton traitement des BDD, tu peux faire que ton traitement appelle les MFC, notamment la fonction PumpMessage() a l'interieur de ta boucle.

Mais tout ça est a condition que tu puisses "sequencer" le traitement.

Sinon, faut faire un WorkerThread, qui fait que du traitement BDD mais ne créé surtout pas d'interface GUI. --> mettre en place une comm entre le thread exclusivement GUI et le thread exclusivement BDD.

@+

Citation:

---

Envoyé par stephdim

attention chaque thread a sa propre pompe a message !!!

appeler PumpMessage() dans un thread pour faire "respirer" un autre thread est impossible ...

---

Ok, c'est noté!

Citation:

---

Envoyé par stephdim

Moi je ferais un seul et unique thread, et le traitement sur les BDD se fera dans CWinApp::OnIdle(). --> remplacer CWinApp par la classe dérivée du projet.

OnIdle() est appelé lorsque la pompe a message est vide, de là tu peux faire un traitement spécifique, mais attention il faut rendre la main régulierement sinon l'appli sera figée. --> Il faut donc "sequencer" le travail a faire par petit paquet pas trop long en terme de temps d'execution.

c'est la methode la plus simple :king:

---

Justement le traitement par paquet n'est pas possible car ça dépend de la taille des tables Oracle manipulées: parfois ça ne prends meme pas un milliseconde et parfois ça prend une minute voir plus. Et bien évidement, je ne peux pas suspendre le traitement d'une table pour "rendre la main" :cry::cry:
Donc à mon avis cette méthode ne peut pas etre une solution.

Mais j'ai une question: OnIdle() est appellée quand la pompe des messages est vide. Supponsons que OnIdle() lance une traitement et au moment que le traitement est en cours un message arrive à la pompe qui sera plus vide. Que se passera-t-il? La pompe va attendre la fin de OnIdle()?? ou bien va prendre la main "par force"??8O8O

Citation:

---

Mais j'ai une question: OnIdle() est appellée quand la pompe des messages est vide. Supponsons que OnIdle() lance une traitement et au moment que le traitement est en cours un message arrive à la pompe qui sera plus vide. Que se passera-t-il? La pompe va attendre la fin de OnIdle()?? ou bien va prendre la main "par force"??

---

Tout est confiné dans le meme thread, c'est justement le role de la pompe à message de "sérialiser" les évènements.

En gros, la boucle des MFC c'est:

Code:

---

1 2 3 4 5

for (;;) { PumpMessage(); // on traite les messages en attente de la pile FIFO OnIdle(); // traitement quand la pile est vide }

---

Il est clair que si OnIdle() prend 10 sec, l'appli sera figée pendant ce temps là, et ne reagira pas aux évènements, ni a l'affichage des fenetres .....


@+

Citation:

---

Envoyé par stephdim

Sinon il y a la methode inverse:

au lieu que ça soit les MFC qui appelle ton traitement des BDD, tu peux faire que ton traitement appelle les MFC, notamment la fonction PumpMessage() a l'interieur de ta boucle.

Mais tout ça est a condition que tu puisses "sequencer" le traitement.

---

Justement ce n'est pas possible de "séquencer" le traitement:cry:
Donc pas trop le choix, faut utiliser un WorkerThread!

Citation:

---

Envoyé par stephdim

Sinon, faut faire un WorkerThread, qui fait que du traitement BDD mais ne créé surtout pas d'interface GUI. --> mettre en place une comm entre le thread exclusivement GUI et le thread exclusivement BDD.

@+

---

Comment mettre en place une comm? Est ce par l'envoi d'un message privé?
Est ce le thread de traitement BDD, qui d'ailleurs doit disposer d'un handle de ma fenetre, doit faire un SendMessage() pour écrire les traces dans cette fenetre?
Merci
@+

Oui tu peux te servir de SendMessage() d'un thread vers un autre. Mais attention, il y a des cas particuliers qui provoquent des deadlock :mrgreen:

tu peux faire ça:

m_pEdit->SetWindowText(...)

sans prob depuis un autre thread

@+

Citation:

---

Envoyé par vonemya

Le dialogue n'est pas créé dans le thread!

Le dialogue c'est une variable globale (créée par new)donc meme les méthodes de la classe CWorkerThread ont accès à cette instance, ce qui est équivalent à ce que tu me dis de faire. Mais ça plante!

---

Bien lire ce que a écrit Farscape ; la CDialog ne doit pas être crée dans un Thread.
Si cela plante c'est comme tu l'écris un problème d'accès concurrent.

Citation:

---

void CMafenetre::OnBouton()
{
AfxBeginThread(TheThread,GetSafeHwnd(),THREAD_PRIORITY_NORMAL) ;
}

---

Il est souhaitable d'utiliser des CEvent plutot pour synchroniser correctement.
Tu vas créer un CEvent qui va tourner en tache de fond et au besoin lui donner la notification de démarrer avec CEvent::SetEvent()

Citation:

---

Envoyé par stephdim

Mais attention, il y a des cas particuliers qui provoquent des deadlock :mrgreen:
@+

---

Problème de partage de variable qui peut se résoudre avec des sections critiques et CCriticalSection
Une section critique c'est basiquement un méchanisme qui verrouille l'accès à une variable donnée déclarée dans un processus fils

Citation:

---

Envoyé par Mat.M

Il est souhaitable d'utiliser des CEvent plutot pour synchroniser correctement.
Tu vas créer un CEvent qui va tourner en tache de fond et au besoin lui donner la notification de démarrer avec CEvent::SetEvent()

Code:

---

1 2 3 4 5

void CMafenetre::OnBouton() { AfxBeginThread(TheThread,GetSafeHwnd(),THREAD_PRIORITY_NORMAL) ; }

---

---

Mais, si je ne me trompe pas, OnBouton(), ne sera appelée que si le message correspondant au click sur le bouton soit traité!!! Ce message est mis en attente parce qu'à ce stade (avant que OnBouton() soit appelée) il n'ya qu'un seul thread qui en train de faire des traitements BDD, donc pas le temps de traiter ce message --> OnBouton n'est pas appelée et par conséquent le thread n'est pas crée!!

Si tu as le temps, est ce que tu peux regarder le code que j'ai mis en ligne à cette adresse:
http://www.megaupload.com/?d=4RRCS0JE
Je simule mon bug

Je viens de jetter un oeil a ton source et je trouve que tu te compliques vachement la vie !! :mrgreen:

J'ai pas vu de thread dans ton source ; mais en gros voila ce qu'il faut faire:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

void CAffichageTracesDlg::OnLancerApplication() { CFenetreLog *pDlg=new CFenetreLog(....); // on créé la fenetre   ... // on affiche la fenetre ....   AfxBeginThread(fctPrincipale,pDlg); // on créé un thread et on passe en paramètre le pointeur de la fenetre "Log"   // c'est tout }   UINT __cdecl fctPrincipale(LPVOID pParam) // la procédure du thread { CFenetreLog *pDlg=(CFenetreLog*)pParam; // on récupère le pointeur de la fenetre "Log"   ..... // on fait du taff   pDlg->afficherTrace("un joli message");   ..... // et ainsi de suite   return 0; // le thread est fini }

---

Tu conserves tel quel ta fonction afficherTrace (c'est parce que les fonctions utilisées par afficherTrace renvoies vers des SendMessage() (wrapper de CEdit) que ça marche )

Ca devrait fonctionner sans probleme.

Pourquoi faire des dialogues dynamiques ?!? je trouve que ça fait un peu usine à gaz pour juste faire ça ... enfin bon c'est hors sujet ça

@+

Citation:

---

Envoyé par farscape

la dialogue ne doit pas être crée dans le thread
si l'appel se fait à partir d'une interface (dialogue par exemple).
tu créés ta dialogue non modal par un new ,tu stocks le pointeur dans l'interface en tant que donnée membre.
Au moment de l'AfxBeginThread tu fournis un pointeur de l'interface au thread.
dans le thread tu as donc accès a l'interface et au pointeur sur la dialogue non modale.

---

c'est exactement ce que j'avais conseillé de faire ..

Merci farscape et stephdim :king: ça marche bien.

Mais j'ai une 2ème application très semblable à celle que j'ai décrite. Il y a une seule petite différence qui apparemment fait en sorte qu'on arrive pas à écrire dans la fenetre.

Dans cette 2ème application, la méthode d'ecriture dans le fenetre afficherTrace() est appelée indirectement dans la fonction fctPrincipale() exécutée par le second thread crée. Je m'explique:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

void fonction1() { .... // on appelle la fonction afficherTrace(message); ..... } void fonction2() { .... // on appelle la fonction afficherTrace(message); ..... } void fonction3() { .... // on appelle la fonction afficherTrace(message); ..... } ..... ..... UINT __cdecl fctPrincipale(LPVOID pParam) // la procédure du thread { //pDlg est déclaré local à la fctPrincipale() CFenetreLog *pDlg=(CFenetreLog*)pParam; // on récupère le pointeur de la fenetre "Log" ..... // on fait du taff fonction1; fonction2; fonction3; ....... ....... ..... // et ainsi de suite return 0; // le thread est fini }

---

Donc vous voyez bien que la portée du pointeur pDlg ne doit pas se limiter à la fonction fctPrincipale()!!
Comme il y a plein de fonctions appelés dans fctPrincipale() et qui appellent de leur tour afficherTrace(comme fonction1,fonction2...) je ne peux pas passer pDlg en parametre, ça demande des énormes modif dans le code.
Quand ej dis plein c'est un fichier de 25743 lignes exactement 8O8O c'est pas moi qui l'ai fait.

Donc j'ai essayé de declarer pDlg en tant que variable globale et dans la fonction fctPrincipale() je lui affecte le pointeur passé en parametre à cette dernière. Mais rien en s'affiche dans la fenetre:cry: Avec des fprintf je suis sûr que les traitements sur la BDD tournent bien dérrière et la fenetre qui reste sans message(la fonction afficherTrace échoue) ne plante pas!

Une idée pour remedier à cela??

Thanks!

ben ça ne devrait pas poser de probleme.

Si ça marche avec une, ça marche avec plus de fonctions.

Tu mets le pointeur de CFenetreDlg dans une var globale avant de créer le thread (pas la peine de le passer en param a la fonction du thread, si la var est globale)

Un truc: ne pas oublier de faire un delete, sinon tu auras un memory leak

@+

Citation:

---

Envoyé par stephdim

ben ça ne devrait pas poser de probleme.

Si ça marche avec une, ça marche avec plus de fonctions.

Tu mets le pointeur de CFenetreDlg dans une var globale avant de créer le thread (pas la peine de le passer en param a la fonction du thread, si la var est globale)

Un truc: ne pas oublier de faire un delete, sinon tu auras un memory leak

@+

---

J'ai fais comme tu m'as dit: j'instancie ma fenetre et le pointeur que je récupère je l'affecte à un pointeur global pDlg et puis , une fois le thread est crée afficherTrace() est appelé à partir de ce pointeur(pDlg->afficherTrace()) mais ça marche po le fonction afficherTrace() n'est meme pas appelé(un MessageBox à l'interieur le prouve)

Citation:

---

Envoyé par vonemya

J'ai fais comme tu m'as dit: j'instancie ma fenetre et le pointeur que je récupère je l'affecte à un pointeur global pDlg et puis , une fois le thread est crée afficherTrace() est appelé à partir de ce pointeur(pDlg->afficherTrace()) mais ça marche po le fonction afficherTrace() n'est meme pas appelé(un MessageBox à l'interieur le prouve)

---

Je me rattrappe; ça marche nickel! Je suis encore en train d'effectuer des tests, pour l'instant tous les tests reussissent. Je vais tester encore et encore.

Merci beaucoup pour votre aide précieuse.