[MFC]Pourquoi CreateNewFrame() renvoie NULL en RELEASE.

Bonjour,


J'ai crée une application MFC qui marche très bien en debug mais lorsque que je le compile en release le programme plante dans le InitInstance() au démarche et affiche "La création d'un document vide a échoué"

Je mets des points d'arrêt et je tombe dans le multidoctemp dans OpenFileDocument()

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

CDocument* CMultiDocTemplate::OpenDocumentFile(LPCTSTR lpszPathName, BOOL bMakeVisible) { CDocument* pDocument = CreateNewDocument(); if (pDocument == NULL) { TRACE(traceAppMsg, 0, "CDocTemplate::CreateNewDocument returned NULL.\n"); AfxMessageBox(AFX_IDP_FAILED_TO_CREATE_DOC); return NULL; } ASSERT_VALID(pDocument); BOOL bAutoDelete = pDocument->m_bAutoDelete; pDocument->m_bAutoDelete = FALSE; // don't destroy if something goes wrong CFrameWnd* pFrame = CreateNewFrame(pDocument, NULL); pDocument->m_bAutoDelete = bAutoDelete; if (pFrame == NULL) { AfxMessageBox(AFX_IDP_FAILED_TO_CREATE_DOC); delete pDocument; // explicit delete on error return NULL; } ASSERT_VALID(pFrame);

---

Voilà, si quelqu'un a une idée, ou une solution a me faire partagé j'en serais ravis.
:(

salut,
en général c'est un probleme avec les ressources.
post ton initinstance , la partie qui declare le doctemplate de cette vue.

Voici le code,

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 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61

BOOL CVisualHydroBilApp::InitInstance() { INITCOMMONCONTROLSEX InitCtrls; InitCtrls.dwSize = sizeof(InitCtrls); // Set this to include all the common control classes you want to use // in your application. InitCtrls.dwICC = ICC_WIN95_CLASSES; InitCommonControlsEx(&InitCtrls); // Initialize OLE libraries // AfxOleInit() is already calling in HydroBil module AfxEnableControlContainer(); if( !MCN::ManagementConsole::CMcnWinApp::InitInstance() ) { AfxMessageBox("Echec d'intialisation de la console MCN", MB_ICONSTOP); return FALSE; } m_bInitialized = true; LoadStdProfileSettings(4); if( !MCN::ManagementConsole::CMcnWinApp::CreateMcnMCMultiDocT( IDR_VisualHydroBilTYPE, RUNTIME_CLASS(CVisualHydroBilDoc), RUNTIME_CLASS(CChildFrame), // custom MDI child frame RUNTIME_CLASS(CVisualHydroBilView)) ) return FALSE; // create main MDI Frame window CMainFrame* pMainFrame = new CMainFrame; if (!pMainFrame || !pMainFrame->LoadFrame(IDR_MAINFRAME)) { AfxMessageBox("Echec de chargement de la frame principale de l'application", MB_ICONSTOP); delete pMainFrame; return FALSE; } m_pMainWnd = pMainFrame; m_pMainWnd->DragAcceptFiles(); // Enable DDE Execute open EnableShellOpen(); RegisterShellFileTypes(TRUE); // Parse command line for standard shell commands, DDE, file open CCommandLineInfo cmdInfo; ParseCommandLine(cmdInfo); // Dispatch commands specified on the command line. Will return FALSE if // app was launched with /RegServer, /Register, /Unregserver or /Unregister. if (!ProcessShellCommand(cmdInfo)) // les ennuis commençent ici return FALSE; // The main window has been initialized, so show and update it pMainFrame->ShowWindow(SW_SHOWMAXIMIZED); pMainFrame->UpdateWindow(); m_bInitialized = true; return MCN::ManagementConsole::CMcnWinApp::CloseSession(FALSE); }

---

re,
ton code n'est pas standard ...
ou est le AddDocTemplate ?
si tu ecris une séquence standard MFC avec un CMultidocTemplate + AddDocTemplate ça fonctionne ?
dernier truc si tu remplaces
IDR_VisualHydroBilTYPE par IDR_MAINFRAME ça fonctionne ?

EUREKA :D :D :D

En tout cas j'ai appris quelque chose de neuf. Le bug était vraiment bien embusqué. Il ne s'agissait pas d'un problème de ressources ou des appels à AddDocTemplate car dans mon code je le faisais.

Le problème remontait bien haut dans la chaine des appels. Et particulièrement dans mes DLLs MCN chargées par l'application.

Voici ce que j'ai découvert. Dans nos programmes MFC ou ATL on rencontre souvent des instructions tels que ASSERT(expr) ou ATLASSERT(expr). Ces instructions sont des macros définits dans les headers des MFC/ATL et ses macros nous permettent de certifier qu'une expression est correcte, exacte ou vrai. Lorsque l'expression est fausse, Visual C++ affiche une boite de dialogue de violation d'une assertion.

Cependant VC++ exécute ses macros qu'en DEBUG et non en RELEASE.

Or que ce passait-il dans mon code?
Généralement dans ces macros, on évalue des expressions qu'en lecture seule et non en écriture c à d.

expression en lecture seule juste à des fins de testes.

Code:

---

1 2 3

ATLASSERT(::IsMenu(hMenu) && GetSafeHwnd()); // good en debug et en release ATLASSERT(a >= B); // good en debug et en release

---

ces instructions ci-haut sont exécutées en debug mais pas en release. Mais ça ne dérange pas tant que l'expression est en lecture seule.

expression en écriture

Code:

---

1 2 3

ATLASSERT(pMcnMenu->Attach(pSubMenu->m_hMenu)); // good en debug mais pas en release ATLASSERT(pMcnMenu = new CMcnMenu()); // good en debug mais pas en release

---

ces instructions ci-haut sont exécutées en debug mais pas en release. Mais ça dérange ENORMEMENT car pMcnMenu ne reçoit jamais l'handle de menu ou n'est jamais alloué dynamiquement car l'expression est en écriture et se trouve dans un ATLASSERT. Et VC++ saute cet ATLASSERT en release d'où mon objet CMcnMenu n'est jamais affecté. Ce qui entraîne des conséquences dans la suite de la chaînes des appels jusqu'à ce que CreateNewFrame me renvoie NULL dans le CMultiDocTemplate.

Ainsi j'ai repassé au peigne fins tout le code de mes dlls et de mon programme et ce dernier fonctionne impeccablement. :D

Cette remarque des assertions dans figurer dans la FAQ VC++ ;)