Thank you Honza

This would mean that all GUI user classes must have virtual destructors?

Thank you Honza

This would mean that all GUI user classes must have virtual destructors?

Hello all

I have random problems with GUI controls. Sometimes with DEBUG or RELEASE, when a control is destructed an EXCEPTION_ACCESS_VIOLATION exception raises. This happens in ScatterCtrl.
For example, function ScatterCtrl::DoShowEditDlg() calls PropertiesDlg(*this, itab).Run(true) opening a dialog.
Sometimes, when this dialog is closed, this errror raises. The function call stack represets basically destructors:



It is like there is a problem in the destructors order, so that in this case, when ColorPusher destructor is called, parent controls has been already destructed.

I have seen that many or maybe all GUI controls have virtual destructors. Maybe it has no sense but, should GUI user controls destructors have to be also virtual?

Hello Mirek

I did not know that 'virtuality' of destructor is inherited. In fact high level U++ GUI classes like ArrayCtrl have empty virtual destructors.

It is like some destructor supposes that parent control already has not been closed.

Two samples:

void PropertiesDlg::OnClose() 
{
	measures.Change();
	
	RejectBreak(IDOK);
	Close();	Close();
}

It should not be a reason for these problems, but Break should be enough here. Why do you call Close twice after that?

Mirek

Well, this does not solve the problem but solves the exception:

void ScatterCtrl::DoShowData() 
{
	static DataDlg dlg;
	ONCELOCK {
		dlg.Init(*this);
	}
	dlg.Run(true);
}

It has been applied to all problematic dialogs. The problems have not been repeated.

BTW, why do you use appmodal mode (Run(true))? That is not standard.

Quote:

BTW, why do you use appmodal mode (Run(true))? That is not standard.

What do you recommend?

Well, this does not solve the problem but solves the exception:

void ScatterCtrl::DoShowData() 
{
	static DataDlg dlg;
	ONCELOCK {
		dlg.Init(*this);
	}
	dlg.Run(true);
}

It has been applied to all problematic dialogs. The problems have not been repeated.

Finally the cause was totally unrelated with ScatterCtrl and was caused by SetTimeCallbacks not handled properly.

It has been difficult to find this, but the problems must not be swept under the carpet, and the root cause of them has to be found. A patch is not a solution