Newsgroup: it.comp.programmare.win32
Titolo: Dialog and asserts

Hi,
	I have a dialog based application and I want to open another
dialog. I have a function 
int CMyDialog::Execute
{ // CMyDialog::Execute
	int ret_code;
	CNewDialog m_NewDialog(this);
	ret_code = m_NewDialog.DoModal();
	return ret_code;
} // CMyDialog::Execute
that opens this dialog but this fail :(
I got at assert on this line
BOOL CWnd::Attach(HWND hWndNew)
{
--->	ASSERT(m_hWnd == NULL);     // only attach once, detach on 
I have realized my application with the Wizard so I am not
very expert about this stuff.
Can someone tell me what's happening ?
       Stefano Malavasi
__________________________________________________________________________________________
Email:		s_malavasi_REMOVE_@_REMOVE_lycos.it
Note: 		Remove _REMOVE_ string to reply

Stefano, the assertion you are getting is what looks like when a window is
being subclassed more than once.The code you have shown here looks fine. You
may have done something with the variable mebers of the dialog. What you
should do is when you get the assertion go back a step at a time in the
stack to see where it all started from in your code. To do that you need to
have some basics in how classes and functions are called and how to use the
tool. If you want to try, when the assertion happens click try, then check
in the bottom left hand corner (unless you have moved it). There should be a
ComboBox that lists all the function calls in the stack.
Saluti
Lorenzo
"Stefano Malavasi" <s_malavasi_REMOVE_@_REMOVE_lycos.it> wrote in message
news:0bmpsvodlrbs69nso...@4ax.com...



Grazie per la risposta e scusa il post in inglese pensavo di essere su
un altro NG :(
Premesso che sono passato dalla programmazione C a quella in VC++
quindi mi mancano sicuramente delle basi sulla gestione delle
finestre, ancora non riesco a trovare il problema :(
Ho creato quasi tutto con il wizard tranne alcuni classi ottenute come
subclassing di CStatic e CEdit che pero' erano presenti anche in
dialoghi precedenti a quello che da errore ...
Ho fatto quanto mi hai suggerito e questo e' lo stato dello stack.
CRev_Selezine e' il dialogo chiamante, CMisure e' quello chiamato
non capisco pero' dove cercare il problema :(
(Un'altra domanda. E' meglio allocare i dialoghi sullo stack o
sull'heap tramite new CMyDialog con conseguente delete dopo l'uso ?)
CWnd::Attach(HWND__ * 0x000205e2) line 311 + 28 bytes
CWnd::SubclassWindow(HWND__ * 0x000205e2) line 3845 + 12 bytes
CWnd::SubclassDlgItem(unsigned int 1083, CWnd * 0x000d1d94 {CMisureDlg
hWnd=???}) line 3883 + 12 bytes
CMisureDlg::OnInitDialog() line 6500
AfxDlgProc(HWND__ * 0x000204f8, unsigned int 272, unsigned int 132518,
unsigned int 132518) line 35 + 14 bytes
USER32! 77e12e98()
USER32! 77e21a8c()
USER32! 77e1736d()
USER32! 77e16a72()
USER32! 77e16aee()
CWnd::DefWindowProcA(unsigned int 272, unsigned int 132518, long 0)
line 1000 + 32 bytes
CWnd::Default() line 249
CDialog::HandleInitDialog(unsigned int 132518, unsigned int 132518)
line 624 + 8 bytes
CWnd::OnWndMsg(unsigned int 272, unsigned int 132518, long 0, long *
0x000d1a10) line 1815 + 17 bytes
CWnd::WindowProc(unsigned int 272, unsigned int 132518, long 0) line
1585 + 30 bytes
AfxCallWndProc(CWnd * 0x000d1d94 {CMisureDlg hWnd=???}, HWND__ *
0x000204f8, unsigned int 272, unsigned int 132518, long 0) line 215 +
26 bytes
AfxWndProc(HWND__ * 0x000204f8, unsigned int 272, unsigned int 132518,
long 0) line 368
AfxWndProcBase(HWND__ * 0x000204f8, unsigned int 272, unsigned int
132518, long 0) line 220 + 21 bytes
USER32! 77e12e98()
USER32! 77e14876()
USER32! 77e1d6a1()
USER32! 77e1ddbf()
USER32! 77e253c1()
CWnd::CreateDlgIndirect(const DLGTEMPLATE * 0x006b6088, CWnd *
0x00121321 {CRev_SelezioneDlg hWnd=???}, HINSTANCE__ * 0x00400000)
line 327 + 36 bytes
CDialog::DoModal() line 531 + 32 bytes
CRev_SelezioneDlg::ExecuteMisure() line 772 + 11 bytes

 sull'heap tramite new CMyDialog con conseguente delete dopo l'uso ?)
Dipende, se usi troppo lo stack non e infinito. Pero uzando lo stack e piu
facle di sapere che hai pulito dietro siccome il destructor viene chiamato
automaticamente. Che ti posso dire, re-uso, efficienza e facilita d'uso.
Lorenzo

automaticamente. Che ti posso dire, re-uso, efficienza e facilita d'uso.
In termini di efficienza e prestazioni però uno vale l'altro ?
Ora però mi ritrovo con un nuovo problema. 
All'uscita del dialogo mi da sempre un errore
DAMAGE after client block (NNNN) at YYYYY
quando cerco di rimuovere la variabile della classe. Ho provato
ad allocarla sull'help tramite new e la rimuovo dopo il DoModal con
una delete. E proprio la delete mi da quell'errore. 
Cercando su google ho visto che dovrebbe trattarsi
di un problema di allocazione/deallocazione di memoria
Ho commentato per intero OnInitDialog, il costruttore
della classe chiamata  e anche DDX ma l'errore resta. Dove
posso ancora cercare ?

 una delete. E proprio la delete mi da quell'errore.
Questa e facile. Vede. Nessuna finestra si deve distruggere con delete ma
usi
item->DestroyWindow()
E una dei stranezzi dell Windows. Per essere sicura che hai pulito tutto
guarda nella finestra del debug windows e vedi se ci sono memory leaks
quando chiudi il tuo programma.

item->DestroyWindow()
Grazie ancora per la risposta. Il codice e' 
	Dialog2 = new CDialog2;
	Dialog2->DoModal()
	delete Dialog2 <---- Errore
Questa delete da l'errore descritto.

 Questa delete da l'errore descritto.
si questa e la problema. Non so perche i figli di Bill hanno fatto questo,
forse per mantere la filosofia con il passato, ma non ho mai investigato la
cosa fino in fondo

cosa fino in fondo
Quindi anziche' delete dovrei deallocare con DestroyWindow o fare la
DestroyWindow prima della delete ?

No. Nessun delete. Solo DestroyWindow. Capisco che ti sembrera strano ma e
cosi. Prova e vedrai che anche se fai delete dopo DestroyWindow avrai
problemi. Poi togli il delete e vedrai che nell debug window non ci saranno
leaks
"Stefano Malavasi" <s_malavasi_REMOVE_@_REMOVE_lycos.it> wrote in message
news:l52vsvo6ijt6rutbo...@4ax.com...


 No. Nessun delete. Solo DestroyWindow.
Per complemento, consiglio la lettura della nota tecnica "TN017:
Destroying Window Objects" su MSDN. Esistono dei casi in cui si puo`
usare il delete, ma la sostanza e` che dato che DestroyWindow() va
sempre bene, e` piu` sicuro usare sempre quello.
-- 
Lorenzo

sempre bene, e` piu` sicuro usare sempre quello.
Io ho utilizzato il  DestroyWindow ma con RationalPurify quella riga
mi viene evidenziata come Memory Leak potenziale.
       Stefano Malavasi
__________________________________________________________________________________________


leaks
Io ho utilizzato il  DestroyWindow ma con RationalPurify quella riga
