Discussion :

[r0d]

Bonjour à tous,

j'ai actuellement quelques soucis avec la destruction des fenêtres de mon appli (quand on clique sur la petite croix p. ex.) , et je me rends compte que certaines choses m'échappent. C'est pourquoi je m'en remet à vous:

* Ma fenête hérite de CChildFrame. Elle contient une CView, qui contient elle-même des controles divers et variés. Lorsque je la ferme, ça plante dans CView:: PostNcDestroy().
* Le destructeur de la frame n'est pas appelé, mais celui de la view oui. Comment se fais-ce? Qui appelle ces destructeurs?
* Dois-je intercepter le WM_ON_DESTROY? Si oui, que dois-je faire dedans?
* Comment sont détruits les objets GDI? Comment s'assurer qu'ils sont bien détruits?

Merci d'avance pour les multiples réponses que vous aller me donner

[farscape]

salut,
la question initiale c'est pourquoi ça plante...
et qu'est ce qui plante ?

[farscape]

je complète : la fenêtre détruit sa partie graphique sur la destruction de l'objet.
Donc dans le cas des contrôles quand la donnée membre est détruite.
pour les contrôles non associé à une variable un message est envoyé
sur la destruction de la fenêtre mère.

[mat.M]

Les objets alloués sont désalloués avec la classe de Document.
C'est ça la philosophie MFC .
Je ne comprends pas pourquoi tu fais hériter des objets de CChildFrame.
Une classe CView est toujours associée à une CDocument ...

* Comment sont détruits les objets GDI? Comment s'assurer qu'ils sont bien détruits?

?? Les objets GDI sont , en général , crées lorsque tu dessine avec OnDraw et désalloués immédiatement après.
S'ils sont membres de la CView et persistants durant l'existence de la classe il faut les effacer au destructeur de la CView


Je te conseille le livre de M$ Press "Atelier Visual C++" ou "Programming the MFC" de Jeff Prosise

[farscape]

pour les objets GDI si ils sont utilisés à travers une classe MFC ;il y a destruction de la partie GDI sur la destruction de l'objet.

[r0d]

salut,
la question initiale c'est pourquoi ça plante...
et qu'est ce qui plante ?

Alors, ça plante quand je ferme la fenêtre (frame). Je ne sais pas exactement où (code asm) mais la dernier méthode "accessible" dans la call stack est CView:: PostNcDestroy().
Quand ça plante, j'ai un message "user breakpoint called", et si je continue (F5), je reçoit le sympathique petit message:

Program: D:\path\monprog.exe
File: dbgheap.c
Line: 1044

Expression: _CrtIsValidHeapPointer(pUserData)

Je suis en debug, sous VC6 ( ) et je dois partir très vite donc si tu me réponds, je ne pourrais lire la réponse que demain

Merci et bonne soirée.

[farscape]

dbgheap est un problème de débordement mémoire quelque part sur un pointeur
....
En gros tu as une utilisation illicite qui corrompt la mémoire..

[r0d]

Je ne comprends pas pourquoi tu fais hériter des objets de CChildFrame.

Alors en fait voilà: j'ai une application de type MDI avec ma mainframe. Moi je veux créer une nouvelle fenêtre, qui est constituée ainsi:
- la frame, qui hérite de CChildFrame, qui contient:
- une dialog bar (qui contient, elle aussi, tout un tas de contrôles)
- une view, qui hérite de cdxCDynamicFormView (cf codeproject)
Ma frame hérite de CChildFrame car elle hérite d'une classe particulière à l'appli sur laquelle je travaille, et je n'ai pas vraiment le choix en fait.
Ma frame est créée ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CMDIChildWnd* pWnd = m_pMainFrame->CreateNewChild(RUNTIME_CLASS(CMaFrame), IDR_MON_ICONE);

Une classe CView est toujours associée à une CDocument ...

Bah oui mais le problème c'est que je n'ai pas besoin de CDocument.

Je te conseille le livre de M$ Press "Atelier Visual C++" ou "Programming the MFC" de Jeff Prosise

Oui, je crois que j'en ai bien besoin... je vais les commander de ce pas

[farscape]

tu n'as pas besoin de CDocument ok, le framework oui alors laisse le fonctionnement par defaut en donnant la classe CDocument .
comme je l'ai déjà dit on n'est pas obligé d'utiliser les fonctionnalités du document openfile etc...

[r0d]

D'accord, mais j'en fais quoi de mon CDocument? Quand je créé ma fenêtre (CreateNewChild), il ne me demande pas de CDocument. Et puis ma fenêtre fonctionne bien (à part ce plantage à la fermeture)

[farscape]

voir faq:http://c.developpez.com/faq/vc/?page...ltiDocTemplate


tu definis ton document template et tu l'appelles par OpenDocumentFile(NULL...

[r0d]

hmphffftssss... j'ai l'impression que je n'ai pas besoin de faire cela (le DocTemplate), car quand je regarde ma view en debug, son m_pDocument est mis à NULL par défaut (j'espère qu'en release ce sera pareil, je n'ai pas encore testé).

En revanche, comme je disais, ça plante dans cette fonction:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
// self destruction
void CView::PostNcDestroy()
{
	// default for views is to allocate them on the heap
	//  the default post-cleanup is to 'delete this'.
	//  never explicitly call 'delete' on a view
	delete this;
}

et là, le this->hWnd est à NULL. Je ne sais pas si c'est normal

[Gabrielly]

Citation:
r0d a écrit :
* Comment sont détruits les objets GDI? Comment s'assurer qu'ils sont bien détruits?

?? Les objets GDI sont , en général , crées lorsque tu dessine avec OnDraw et désalloués immédiatement après.
S'ils sont membres de la CView et persistants durant l'existence de la classe il faut les effacer au destructeur de la CView

Vu que tu as une panne dans ta vue, je me demande comme est ce que tu utilises tes objets GDI.

Le principe est que tu crées tes objets GDI,
tu les séléctionnes dans le DC
et ensuite tu restaures les anciens objets GDI qui étaient dans le DC

Ces trois étapes doivent être faites dans la méthode qui crées les objets GDI et ces derniers doivent être détruit dans cette même méthode avant qu'elle ne retourne à son appelant.

Si tu as besoin de persistance de tes objets GDI, alors ne stocke pas de pointeur comme données membres pour en faire des delete à la fin sinon . Mais stocke plutôt des handles des GDI.
Parce que les objets du GDI ont une durée de vie un peu bizarre lié à l'OS

[Gabrielly]

Si ça c'est fait
alors le problème est ailleurs.
Sinon il faudra faire 100 pompes et relire tes cours de C++

[r0d]

Sinon il faudra faire 100 pompes et relire tes cours de C++

Encore!!! Relire les cours de c++, ok, mais 100 pompes

En fait, j'ai laissé tomber pour l'instant, je suis sur un autre problème bien galère. En fait, ma fenêtre utilise diverses libs graphiques, et j'ai de gros soucis d'incompatibilité... erf, c'est pas toujours facile de se frayer un chemin hors des entiers battus

[r0d]

Salut à tous,

juste pour signaler, pour ceux que ça intéresse, que ce que j'essaie de faire semble parfaitement possible: How to add multiple window types to a non-document view MDI application

Mais je ne comprends toujours pas pourquoi le destructeur de ma CView est appelé 2 fois

[farscape]

oui c'est possible ça sort des chemins standards ,
et je me demande encore pourquoi tu t'embetes tant ...

[r0d]

Erf, moi aussi je me demande
Non, en fait, c'est qu'on essaie un truc. Et il n'y a plus que cette histoire de destruction qui déconne... on y est presque.
En fait, je ne peux pas utiliser le MultiDocTemplateTruc parce que cela ne fonctionne pas avec "l'architecture" que je souhaite avoir, à savoir:
- Une frame un peu particulière qui hérite d'une classe très particulière inhérente à l'appli sur laquelle je travaille.
- Une view très particulière qui hérite de cdxDynamicMachinTruc
- Pas de Document.
J'avais essayé avec le MultiDocTemplateBidule, mais cela ne fonctionnait pas