[MFC] Processus qui ne s'arrête pas quand la boîte de dialogue se ferme

Bonjour à tous,

je viens de finir une boîte de dialogue MFC qui fonctionne à peu près correctement.

Contexte : globalement, le programme écrit un fichier (.dgibi) qui est ensuite ouvert par un logiciel de calcul (Cast3M pour ceux qui connaissent). Une fois le calcul terminé, le logiciel se ferme et le programme MFC reprend la main pour se servir des résultats. Un traitement est fait sur les résultats puis le fichier (.dgibi) est réécrit, puis relancé par le logiciel etc.... jusqu'à ce qu'un des critères de convergence soit atteint.

Problème : lorsque je quitte la boîte de dialogue, les calculs continuent toujours. Je suis obligé de fermer le processus un peu sauvagement par le gestionnaire des tâches Windows.

Je me doute bien que l'erreur vient de moi mais je ne vois pas vraiment comment faire pour régler le problème.

Merci d'avance

Est-ce une application dialog-based, avec un DoModal() dans le InitInstance()?

Oui c'est une application dialog-based.
Non, je n'ai pas de IniInstance().
En revanche, j'ai un DoModal() dans le OnSysCommand().

Oula, désolé. J'ai répondu complètement à côté de la plaque.

Oui effectivement, il y a bien un DoModal() dans le InitInstance().

Et en attachant le débuggeur de VS à la place d'utiliser le gestionnaire des tâches, ça vous donne quoi comme code en cour d'exécution ?

Quand je me mets en mode DEBUG et que je clique sur le bouton "Quitter" de ma boîte de dialogue, ça ferme l'application mais le calcul continue toujours derrière.

Pour que ça s'arrête, il faut que j'arrête le débogueur et là tout se ferme.

Autrement dit, ça fait la même chose que ce que j'ai décrit dans mon premier post.

Quel calcul?
Normalement dans le cas "classique" de fenêtre fermée sans quitter la boucle de messages, tout ce que le programme fait, c'est une attente passive.

Citation:

---

Quel calcul?

---

Pardon si je ne suis pas clair.

L'application lance un exécutable qui fait des calculs sur mon fichier (.dgibi) que j'écris juste avant. Une fois le calcul terminé, l'exécutable se ferme automatiquement et mon application (boîte de dialogue) charge les résultats du calcul.

Si je clique sur mon bouton "Quitter" pour fermer la boîte de dialogue, et bien dans le gestionnaire des tâches, il y a toujours mon application qui est ouverte et les calculs continuent. Je le sais parce que dans le gestionnaire, l'exécutable (qui fait les calculs) apparaît et disparaît successivement.

Hé bien il faut savoir comment exactement ton programme Dialog attend la fin du programme Calcul, et savoir ce que tu veux faire précisément quand on quitte le programme Dialog:

• Quitter le programme Dialog complètement mais laisser le programme Calcul tourner jusqu'à la fin (l'état actuel, si j'ai bien compris)
• Tuer le programme Calcul avant de quitter le programme Dialog
• Tenter d'interrompre le programme Calcul proprement, et le tuer s'il ne se termine pas in X secondes

etc.

Le problème, c'est que tu risques de ne même pas pouvoir essayer de quitter le programme Calcul proprement, s'il s'agit d'un programme externe dont tu n'as pas les sources; dans ce cas, tu vas être obligé de tuer le processus (via TerminateProcess()).

Oui je comprends.

Mais du coup, je ne comprends pas la chose suivante : à la base, j'avais un programme en console qui faisait EXACTEMENT la même chose et quand je cliquais sur "Fermer", la console se fermait et les calculs s'arrêtaient.

Or j'ai l'impression que le fait de fermer la boîte de dialogue ne la ferme pas vraiment, c'est-à-dire qu'elle ne s'affiche plus, en ce sens elle est fermée, mais son exécutable est toujours présent dans le gestionnaire des tâches. D'où, à mon humble avis, le fait que les calculs continuent.

A mon humble avis, je pense que le problème vient, non pas du fait que les calculs continuent, mais plutôt du fait que la boîte de dialogue reste "active" en quelque sorte. C'est-à-dire qu'elle se ferme quand je clique sur "Quitter" mais son exécutable est toujours en train de tourner. Ce qui explique pourquoi les calculs continuent.

Peut-être que j'ai oublié quelque chose dans le code pour fermer la boîte de dialogue :

Code:

---

1 2 3 4

void CDlg::OnBnClickedCancel() { CDialogEx::OnCancel(); }

---

Citation:

---

Envoyé par js_naka

Mais du coup, je ne comprends pas la chose suivante : à la base, j'avais un programme en console qui faisait EXACTEMENT la même chose et quand je cliquais sur "Fermer", la console se fermait et les calculs s'arrêtaient.

---

Fermer une Console tue tous les processus Console qu'elle contient, plus ou moins proprement (voir fonction CreateConsoleCtrlHandler()), et selon les paramètres un processus fils est créé (ou non) dans la même console...

Cela explique les différences entre les versions console et non-console de ton programme appelant.

Désolé pour le retard mais je viens de résoudre mon problème.

Bon, c'est un peu en mode Mr Bricolage mais bon ça fonctionne.

J'ai défini un booléen dans ma procédure qui lance les calculs, et dès que je clique sur le bouton "Quitter", le booléen change d'état.

Cela provoque la sortie des boucles de calculs et enfin je ferme ma boîte de dialogue. Du coup, tout se ferme correctement.

Merci à vous en tout cas pour votre aide.

Moi, je ne trouve pas que cela soit du bricolage, mais avec un Event ça serait un peu plus carré.

Sans doute mais je ne connais pas du tout Event. Et le peu que je viens de voir à propos de ça sur Internet me fait un peu peur.

Fais gaffe là, il y a pas mal de choses qui s'appellent Event.

Ici, on parle de ceux qui sont des objets du kernel, créés par CreateEvent(), et que MFC wrappe dans la classe CEvent. C'est un peu comme un booléen inter-processus et garanti volatile (ce qui veut dire que l'optimiseur ne va pas venir faire n'importe quoi quand tu le consultes à chaque itération d'une boucle).

Ok, je vais y jeter un coup d’œil quand même mais je ne suis pas certain d'avoir la volonté de le faire.

Je vais perdre beaucoup de temps à essayer de l'implémenter pour finalement le même résultat.

J'ai entendu des spécialistes dire qu'il est déconseillé de programmer en fonction de ses compétences et qu'il faut programmer en fonction du langage utilisé mais là, je vais faire une pause. Je reviendrai dessus plus tard.

En tout cas, merci à vous pour votre aide.

Forum toujours agréable avec des personnes compétentes qui réagissent vite. Que demande le peuple.